Nguồn gốc: Nhóm Amber

tiêu đề cấp đầu tiên

Chính xác thì "DAG" nghĩa là gì?

"DAG" là từ viết tắt của "Directed Acyclic Graph". Đối với những người không quen thuộc với khoa học máy tính, đây có thể là một thuật ngữ khó hiểu, vì vậy chúng tôi giải thích chi tiết từng từ như sau:

- Directed: Dữ liệu của cấu trúc dữ liệu này chỉ được truyền theo một hướng

- Acyclic (acyclic): Về mặt cấu trúc dữ liệu, không thể từ trạng thái hiện tại trở về trạng thái trước đó, tức là "acyclic"

- Đồ thị: Dưới dạng trực quan hóa cấu trúc dữ liệu, cấu trúc được thể hiện dưới dạng tập hợp các mối quan hệ tương hỗ giữa nhiều đỉnh

Chính xác thì cấu trúc DAG trông như thế nào? Kiểm tra cách dữ liệu được sắp xếp là cách tốt nhất để xác định xem cấu trúc dữ liệu là DAG hay chuỗi khối. Phương pháp sắp xếp này đề cập đến cách các giao dịch được sắp xếp kịp thời. Bởi vì chúng ta hiểu thời gian là tuyến tính, nên chúng ta thường nghĩ các sự kiện xảy ra theo một trật tự nhất định. Con người đồng ý với khái niệm về thời gian, và do đó chúng ta đồng ý rằng các sự kiện xảy ra theo trình tự.

Hình trên là một ví dụ về "dãy tổng". Khi xác định được sự kiện nào xảy ra trước, tất cả các sự kiện sẽ có thứ tự chính xác. Trong tổng thứ tự các sự kiện, chúng ta biết chính xác vị trí của từng sự kiện trong tổng thứ tự. Khi sử dụng tổng thứ tự như trong hình, sự kiện A xảy ra trước, sau đó là sự kiện B và sau đó là sự kiện C. Đây là cách các sự kiện được ghi lại trong chuỗi khối.

Tuy nhiên, tổng số thứ tự của sổ cái phân tán có thể hạn chế khả năng mở rộng về thông lượng và độ trễ. Một phần của vấn đề có thể được giải quyết bằng sổ cái "lệnh một phần". Theo thứ tự một phần, thứ tự chính xác của từng sự kiện so với tất cả các sự kiện khác là không xác định. Thay vào đó, chỉ có chuỗi các sự kiện liên quan được biết đến. Chúng ta không chắc chắn về thứ tự của tất cả các sự kiện, nhưng chúng ta có thể xác định thứ tự của các sự kiện phụ thuộc lẫn nhau.

Ví dụ: chúng ta có thể xác định rằng sự kiện B đã xảy ra trước sự kiện C. Tuy nhiên, trong một hệ thống được sắp xếp một phần, chúng tôi không chắc chắn khi nào sự kiện A sẽ xảy ra. Sự kiện A có thể xảy ra trước, sau hoặc thậm chí giữa các sự kiện này. Sự kiện A không liên quan gì đến các sự kiện khác.

Nói chung, tại sao chúng ta muốn biết các giao dịch này được sắp xếp như thế nào? Bởi vì chúng tôi muốn biết làm thế nào một sự kiện gây ra một sự kiện khác xảy ra. Thứ tự một phần không có khái niệm về thời gian, vậy làm cách nào để sắp xếp các sự kiện mà không biết mỗi sự kiện xảy ra khi nào?

"Trật tự nhân quả" là giải pháp cho vấn đề này. Trật tự nhân quả là trật tự từng phần không xét đến thời điểm xảy ra các sự kiện mà chỉ xét mối quan hệ nhân quả giữa các sự kiện. Miễn là chúng ta có thể xác định sự kiện nào gây ra các sự kiện khác, chúng ta có thể sắp xếp các sự kiện này.

Hình trên là một ví dụ về chuỗi nhân quả. Các sự kiện trong hình trên không được đánh dấu thời gian nên không thể xác định chính xác thời điểm các sự kiện này xảy ra. Tuy nhiên, chúng ta có thể thấy rằng A gây ra B xảy ra và B gây ra C và E xảy ra. Sau đó có thể kết luận rằng A cuối cùng gây ra D và F xảy ra. Vì C gây ra D và E gây ra F, chúng ta có thể xác định thứ tự nhân quả của C và D và E và F. Tuy nhiên, chúng ta không cần xác định thứ tự của C và E hoặc C và F, cũng như thứ tự của E so với C hoặc D. Không phải tất cả các sự kiện đều được sắp xếp một phần và có quan hệ nhân quả với nhau, nhưng điều đó không sao vì các sự kiện không liên quan không cần phải được sắp xếp tương đối với nhau.

Bằng cách sử dụng thứ tự nhân quả, chúng tôi sẽ không còn bị giới hạn trong một cấu trúc như "chuỗi sự kiện" và do đó sẽ có thể xây dựng cấu trúc DAG. Các sự kiện không liên quan gì đến nhau thì không cần phải sắp xếp gì cả. Cấu trúc sổ cái phân tán của các giao dịch theo thứ tự nhân quả là DAG, trong khi cấu trúc sổ cái của tổng số thứ tự là chuỗi khối. Vì thứ tự nhân quả cho phép một số giao dịch nhất định bỏ qua hoàn toàn việc đặt hàng, sổ cái dựa trên DAG có lợi thế về khả năng mở rộng về thông lượng và độ trễ so với sổ cái dựa trên chuỗi khối.

tiêu đề cấp đầu tiên

tiêu đề phụ

Làm thế nào để một chuỗi khối được sắp xếp đầy đủ sử dụng DAG?

chữ

Fantom: Một chuỗi khối dựa trên giao thức Gossip sử dụng công nghệ DAG

Mô tả hình ảnh

Ở cấp độ cao, các nút tạo khối sự kiện tạo thành DAG. Fantom sử dụng DAG này của các khối sự kiện và tạo ra một chuỗi khối (một chuỗi các khối đã được xác nhận).

Fantom lưu trữ dữ liệu trong các khối sự kiện, chứa thông tin tài chính, kỹ thuật và các thông tin khác. Khối sự kiện là cấu trúc dữ liệu được tạo bởi một nút duy nhất để chia sẻ giao dịch và thông tin người dùng trên mạng. Trong hình trên, những gì chúng ta thấy là cấu trúc DAG, vòng tròn đại diện cho nút và khối sự kiện được tạo bởi nút. Nó không được hiển thị trong hình trên, nhưng mỗi nút thực sự đang tạo ra các khối sự kiện. Bất cứ khi nào các nút trao đổi thông tin giao dịch, một khối sự kiện được chia sẻ mới sẽ được tạo. Các khối sự kiện được chia sẻ trên mạng. Khi một khối sự kiện giao tiếp với một khối sự kiện khác, khối sự kiện được giao tiếp sẽ lưu trữ thông tin giao dịch của khối sự kiện trước đó, sau đó tạo một khối sự kiện mới. Thông tin này sau đó được chuyển đến khối sự kiện tiếp theo. Thông tin giao dịch được băm và mỗi khối sự kiện chứa các giá trị băm của một hoặc nhiều khối sự kiện trước đó. Điều này làm cho dữ liệu trở nên bất biến, vì không thể sửa đổi hoặc xóa các khối sự kiện trước đó mà không thay đổi hàm băm.

Như thể hiện trong hình trên, vùng màu xanh lục trong cấu trúc DAG của chuỗi Opera là khối sự kiện và chúng giao tiếp với nhau cho đến khi tìm thấy khối sự kiện gọi là khối "Clotho" (khối màu xanh trong hình trên) . Các khối Clotho chứa một "bảng thẻ", là cấu trúc dữ liệu chứa tất cả dữ liệu kết nối giữa các khối cho một sự kiện cụ thể. Để được coi là một khối Clotho, Clotho phải có kết nối đa số hơn 2/3 với khối sự kiện đã đặt trước đó. Các khối Clotho giao tiếp với các khối Clotho khác trong cấu trúc DAG thông qua cấu trúc dữ liệu bảng thẻ.

Dựa trên thông tin liên lạc với nhau, các khối Clotho đạt được sự đồng thuận để tạo ra một khối sự kiện khác, được gọi là khối "Atropos" (khối màu xanh lá cây trong sơ đồ trên). Mỗi khối Clotho có một dấu thời gian cụ thể khi nó được tạo. Khối Clotho trở thành khối Atropos nếu ít nhất 2/3 số nút có cùng thời gian nút. Các khối Atropos này được xâu chuỗi lại với nhau để tạo thành "chuỗi chính". Chuỗi chính có thể được coi là một chuỗi khối trong cấu trúc DAG. Mỗi khối Atropos được kết nối với các khối Atropos khác, chia sẻ thông tin được thu thập từ khối Clothos, khối này sẽ nhận thông tin của nó từ tất cả các khối sự kiện khác.

Chuỗi chính này chứa tổng thứ tự của tất cả các sự kiện. Tất cả các nút tham gia đều có một bản sao của chuỗi chính và có thể tìm kiếm vị trí lịch sử của các khối của chúng trong giao thức đồng thuận Lachesis. Các nút không cần lưu trữ tất cả thông tin cho từng khối sự kiện, chúng chỉ cần tham chiếu đến chuỗi chính. Điều này cho phép hệ thống nhanh chóng truy cập các sự kiện trước đó.

tiêu đề cấp đầu tiên

DAG với đầu ra theo thứ tự nhân quả

Cái mà hầu hết mọi người gọi là "DAG" thực sự là một sổ cái phân tán được sắp xếp theo thứ tự nhân quả. Các DAG này hoạt động như thế nào và chúng khác với tổng đơn đặt hàng tương đối như thế nào? X-Chain, IOTA và Sui của Avalanche là những ví dụ về sổ cái phân tán có trật tự nhân quả.

Avalanche X-Chain, một DAG dựa trên UTXO.

Bitcoin đã giới thiệu mô hình đầu ra giao dịch chưa sử dụng (UTXO) để ghi lại trạng thái chuyển giữa các ví. Mỗi UTXO là một chuỗi sở hữu và chủ sở hữu ký một giao dịch chuyển quyền sở hữu UTXO sang địa chỉ của chủ sở hữu mới. Trong ngữ cảnh của UTXO, Bitcoin nên được mô tả là một chuỗi khối và X-Chain của Avalanche nên được mô tả là DAG. X-Chain sử dụng giao thức đồng thuận Avalanche theo thứ tự nhân quả. Khi bạn gửi AVAX cho ai đó, bạn đang sử dụng X-Chain. Để hiểu cách DAG của Avalanche hoạt động, trước tiên bạn cần biết cấu trúc DAG của Avalanche được hình thành như thế nào.

Sự đồng thuận của Avalanche được chia thành bốn giai đoạn chính: Slush, Snowflake, Snowball và Avalanche. Đối tác ở giai đoạn cuối cùng với sự đồng thuận của Avalanche là sự đồng thuận của Người tuyết, mà chúng ta sẽ khám phá sau. Trước tiên chúng ta hãy xem cách thức hoạt động của sự đồng thuận Slush. Mạng Avalanche bao gồm nhiều nút. Mỗi nút có ba trạng thái: không trạng thái, đúng và sai. Dưới đây chúng tôi sử dụng màu sắc để thể hiện trực quan hơn: không màu, xanh lam và đỏ.

Mỗi nút bắt đầu là không màu, trong đó nó phải đối mặt với một cuộc bỏ phiếu để quyết định đúng hay sai (xanh lam hoặc đỏ). Khi một màu được chọn, nút giao tiếp với nhiều nút khác trong mạng. Nếu các nút này chưa có màu, chúng sẽ có cùng màu với nút. Nếu phần lớn các nút có cùng màu, nút ban đầu sẽ giữ phiếu bầu đó. Nếu phần lớn các nút có màu khác, thì nút ban đầu sẽ đảo ngược phiếu bầu của nó thành màu đó.

Sẽ có nhiều vòng giao tiếp giữa các nút cho đến khi tất cả các nút đạt được sự đồng thuận. Mục tiêu là để mỗi nút tạo thành một màu nhất quán. Khi một nút nghiêng về một màu nhất định, điều này sẽ củng cố hướng nghiêng đó và hướng kết quả chính xác về màu đó. Khái niệm này là nền tảng mà Avalanche được xây dựng và mọi thứ được xây dựng trên đó.

Khối xây dựng thứ hai của Avalanche là giao thức Snowflake. Mỗi nút có một bộ đếm khi nút nhập bộ nhớ. Bộ đếm được tăng thêm 1 mỗi lần giao tiếp giao thức Slush trả về cùng một màu. Và mỗi khi kết quả đảo ngược nút trả về một màu khác, bộ đếm sẽ được đặt lại. Khi bộ đếm đạt đến một số lượng đủ lớn, nó sẽ khóa trạng thái của nó và ngăn không cho nút thay đổi màu sắc. Điều này sẽ giúp củng cố màu sắc trung thực.

Trong giai đoạn thứ ba của giao thức Snowball, các nút sẽ ghi lại các giá trị với bộ nhớ lớn hơn. Giao thức Snowball tăng thêm độ tin cậy cho giao thức Snowflake. Các nút trong giao thức Snowflake không thay đổi màu sắc dựa trên các nút khác mà chúng giao tiếp, mà thay vào đó xem xét tất cả lịch sử thay đổi màu sắc của chính chúng và thay đổi màu sắc dựa trên trạng thái tin cậy của nút, có tính đến dữ liệu lịch sử thay đổi phiếu bầu của nút đó.

Tất cả các giai đoạn trên cuối cùng dẫn đến giao thức Avalanche. Avalanche là một cấu trúc DAG chỉ nối thêm (thêm giao dịch vào các giao dịch trước đó). Avalanche cũng có thể chạy mà không cần cấu trúc DAG, như trường hợp cấu trúc tuyến tính của Avalanche trên chuỗi hợp đồng (C-Chain) và chuỗi nền tảng (P-Chain). Team Rocket, nhóm phát triển của sự đồng thuận Avalanche, tin rằng kiến ​​trúc DAG vượt trội hơn chuỗi khối, bởi vì việc bỏ phiếu của từng giao dịch trong kiến ​​trúc DAG được liên kết với tất cả các giao dịch mà nó thêm vào, vì vậy cơ chế bỏ phiếu DAG hiệu quả hơn.

Sự đồng thuận của Avalanche bao gồm nhiều sự kiện Quả cầu tuyết để xây dựng một DAG động của tất cả các giao dịch đã biết - mỗi sự kiện Quả cầu tuyết là một đỉnh trong biểu đồ. Các đỉnh giống như các khối trong một chuỗi khối tuyến tính. Nó chứa hàm băm của cha mẹ và một danh sách các giao dịch. Sự đồng thuận của Avalanche dựa trên Snowball và khái niệm về độ tin cậy vẫn còn hiệu lực, nhưng nó được áp dụng cho từng nút của DAG. Khác với quyết định đỏ-xanh đã thảo luận trước đây, các nút trong sự đồng thuận của Avalanche sẽ đánh giá xem một giao dịch có đúng hay không hoặc liệu nó có xung đột với các giao dịch khác hay không và đạt được sự đồng thuận với nhau. Mọi giao dịch được liên kết với một giao dịch gốc và tất cả các giao dịch gốc được liên kết ngược lại với một đỉnh gốc. Một giao dịch có thể có các giao dịch phụ và các giao dịch phụ được liên kết với tất cả các giao dịch chính. Avalanche yêu cầu một đỉnh gốc vì nó yêu cầu một giao dịch phải là cơ sở của tất cả các giao dịch khác (IOTA cũng có một đỉnh gốc); đỉnh gốc rất quan trọng vì các giao dịch chỉ hỗ trợ hoạt động thêm yêu cầu một phần thân thêm. Tuy nhiên, nếu Snowball được áp dụng trực tiếp cho DAG bao gồm các nút, điều này sẽ gây ra một vấn đề chưa được giải quyết, đó là xung đột giao dịch hoặc chi tiêu gấp đôi. Vì vậy, Avalanche đã thêm khái niệm "chit" vào Snowball. Khi độ tin cậy đạt đến ngưỡng, một bộ đếm được gọi là chit sẽ được thêm vào giao dịch với giá trị là "1". Nếu không được chỉ định, bộ đếm chit là "0". Nút này sẽ tính tổng các giá trị chít dưới dạng cài đặt độ tin cậy bổ sung, tương tự như độ tin cậy của Snowball. Sau đó, các nút sử dụng tổng số chit để xác định độ tin cậy của một giao dịch và tất cả các giao dịch con của nó (các giao dịch mới được thêm vào nút).

Avalanche có thể tích hợp Slush, Snowflake và Snowball và điều chỉnh chúng thành một chuỗi tuyến tính. Điều này được thực hiện cho sự đồng thuận của Snowman song song với sự đồng thuận của Avalanche, điều này hoàn toàn khác. Không giống như mô hình UTXO của Avalanche, sự đồng thuận của Snowman dựa trên tài khoản. Sự đồng thuận của Snowman được sử dụng cho chuỗi nền tảng (P-chain) và chuỗi hợp đồng (C-chain) của mạng Avalanche. Giao thức hoạt động tương tự như trên, nhưng mỗi đỉnh chỉ có một cha thay vì nhiều cha. Vì vậy, tất cả các đỉnh tạo thành một thứ tự tổng. Điều này cũng thể hiện cấu trúc tổng thể dưới dạng một chuỗi khối, thay vì DAG. Điều này hữu ích cho các ứng dụng cần biết thứ tự giao dịch và sự đồng thuận của Snowman cũng hỗ trợ các hợp đồng thông minh.

Giao thức đồng thuận Avalanche hoạt động rất tốt đối với việc chuyển tiền và cũng có thể được áp dụng cho nhiều giao thức khác. Avalanche đã được sử dụng như một cơ chế tiền đồng thuận cho Bitcoin Cash trước khi tiến hành hard fork cho dự án của chính nó, Bitcoin ABC. Cấu trúc DAG của Avalanche cải thiện tốc độ giao dịch và vì Bitcoin Cash không yêu cầu hợp đồng thông minh nên lỗ hổng không tương thích của DAG với hợp đồng thông minh không ảnh hưởng đến điều này. Trong lĩnh vực thanh toán, Avalanche có thể bỏ qua nhu cầu về hợp đồng thông minh và chỉ nhấn mạnh cách sổ cái dựa trên DAG có thể mở rộng chức năng hiệu quả hơn.

IOTA, một DAG dựa trên giao dịch sử dụng bằng chứng công việc

Cấu trúc trật tự nhân quả của IOTA được gọi là Tangle, một mạng xử lý các giao dịch song song. Tangle là cấu trúc dữ liệu mà IOTA tạo thành DAG. Mảng rối của IOTA bao gồm các giao dịch, trong đó mỗi giao dịch được biểu diễn dưới dạng một đỉnh trong biểu đồ. Khi một giao dịch mới tham gia Tangle, nó sẽ chọn hai giao dịch trước đó để phê duyệt và thêm hai liên kết mới vào biểu đồ.

Trong sơ đồ bên dưới, giao dịch G phê duyệt các giao dịch E và F. Các giao dịch chứa thông tin như "Alice đã cho Bob mười đồng IOTA". Các giao dịch không được chấp thuận được gọi là "tiền boa". Giao dịch G là một mẹo vì nó chưa được phê duyệt. Mỗi giao dịch mới được thêm vào cần được liên kết với hai mẹo đang chờ xử lý. Có một số chiến lược giúp lựa chọn mẹo, nhưng cách đơn giản nhất là chọn ngẫu nhiên hai mẹo để phê duyệt. Quá trình lựa chọn các mẹo để phê duyệt cực kỳ có thể mở rộng cho các giao dịch mới.

Các giao dịch màu đỏ I và G là các mẹo chưa được phê duyệt vì chúng không được liên kết với bất kỳ giao dịch nào khác. Tất cả các giao dịch khác đã được phê duyệt vì mỗi giao dịch có các giao dịch khác được liên kết với nó.

Đồng thời, IOTA đã giới thiệu trọng lượng, đây là một khái niệm quan trọng để củng cố kiến ​​trúc IOTA DAG. Làm thế nào để chúng tôi biết nếu một giao dịch là đáng tin cậy? Trong một chuỗi khối điển hình, người ta thường thấy số lượng xác nhận của chuỗi khối. IOTA đạt được chức năng tương tự bằng cách xem trọng số giao dịch.

Mô tả hình ảnh

Mỗi giao dịch có trọng lượng riêng và mỗi khi một mẹo được thêm vào mớ hỗn độn, trọng số tích lũy sẽ tăng lên.

Trong sơ đồ trên, chúng ta có thể thấy rằng giao dịch D được phê duyệt trực tiếp bởi các giao dịch E và H, cũng như gián tiếp bởi G và I. Do đó, trọng lượng tích lũy của D là 3+1+3+1+1=9, là tổng trọng số của chính nó cộng với trọng số của E, H, G và I.

Các giao dịch có trọng số tích lũy lớn hơn quan trọng hơn các giao dịch có trọng số tích lũy nhỏ hơn. Mỗi giao dịch mới được thêm vào mớ tăng trọng số tích lũy của các giao dịch trước đó bằng trọng số của giao dịch của chính nó. Các giao dịch cũ trở nên quan trọng hơn theo thời gian. Bởi vì chúng ta có thể nghĩ rằng không thực thể nào có thể tạo giao dịch với đủ trọng số trong một khoảng thời gian ngắn, nên việc sử dụng trọng số tích lũy có thể tránh được các cuộc tấn công thư rác và các cuộc tấn công véc tơ khác.

Tương tự như X-Chain của Avalanche, cách tiếp cận này, mặc dù có khả năng mở rộng cao, nhưng lại khiến việc tích hợp các hợp đồng thông minh gần như không thể. Vì vậy, để cạnh tranh với các chuỗi hợp đồng thông minh khác, IOTA đang tung ra một lớp hợp đồng thông minh riêng gọi là "Assembly". Hội là một Lớp 2 được sắp xếp đầy đủ được thiết kế để hỗ trợ các hợp đồng thông minh EVM và WASM.

Sui, một DAG hợp đồng thông minh sử dụng Proof of Stake

Mặc dù Sui được phân loại là một trật tự nhân quả trong báo cáo này, nhưng trên thực tế, Sui sử dụng cả trật tự tổng thể và trật tự nhân quả. Kiến trúc xử lý giao dịch của Sui có thể được coi là hai phần: một phần là tổng số thứ tự, các giao dịch phụ thuộc được thực hiện theo trình tự và phần còn lại là thứ tự nhân quả, các giao dịch độc lập được thực hiện song song. Các giao dịch phụ thuộc sử dụng giao thức Narwhal và Bullshark của Sui. Narwhal là một mempool dựa trên DAG, trong khi Bullshark là một giao thức đồng thuận tích hợp với Narwhal để đạt được sự đồng thuận. Các giao dịch phụ thuộc chỉ cần thực hiện theo thứ tự với các giao dịch khác mà chúng được liên kết. Tuy nhiên, Sui có cách tiếp cận khác khi các giao dịch hoàn toàn độc lập. Đối với các giao dịch độc lập, thay vì Narwhal và Bullshark, Sui sử dụng một phương pháp gọi là Phát sóng đồng thuận Byzantine (BCB). Phương pháp này không yêu cầu sự đồng thuận toàn cầu, vì vậy các giao dịch có thể được xử lý và ghi vào sổ cái gần như ngay lập tức.

Mô tả hình ảnh

Bất kể các giao dịch được đặt hàng như thế nào, tất cả các giao dịch được xử lý song song trên cùng một mạng.

Một giao dịch chỉ đơn giản là một thay đổi siêu dữ liệu cho một phiên bản cụ thể của một đối tượng. Một giao dịch lấy các đối tượng làm đầu vào và đọc, ghi hoặc thay đổi các đối tượng đầu vào đó để tạo ra một đối tượng mới được tạo hoặc cập nhật làm đầu ra. Mỗi đối tượng biết hàm băm của đối tượng trước đó đã tạo ra nó.

Mô tả hình ảnh

Sổ cái của Sui là một "kho lưu trữ đối tượng" hoặc "nhóm đối tượng" có dữ liệu được lưu trữ trong DAG. Ví dụ: hành động gửi USDC là hành động cập nhật thuộc tính "chủ sở hữu" của một đối tượng, không ảnh hưởng đến các đối tượng khác.

Sổ cái của Sui là một "kho lưu trữ đối tượng" hoặc "nhóm đối tượng" có dữ liệu được lưu trữ trong DAG. Trong DAG này, các nút là các đối tượng và mỗi mũi tên trong biểu đồ biểu thị một giao dịch cập nhật thuộc tính của một đối tượng nhất định. Không được hiển thị trong sơ đồ này là giao dịch gốc, không chấp nhận đầu vào và tạo ra các đối tượng ở trạng thái ban đầu của hệ thống.

những điểm chính

những điểm chính

Thứ tự nhân quả của các giao dịch dường như có lợi thế hơn tổng thứ tự về tốc độ và thông lượng. Tuy nhiên, việc thiếu thứ tự sắp xếp nhân quả tạo ra các vấn đề khi cố gắng tạo các ứng dụng yêu cầu thứ tự thời gian nghiêm ngặt và nhiều dự án không thể chạy đúng hợp đồng thông minh trên kiến ​​trúc DAG của họ. Kiến trúc được sắp xếp đầy đủ của Fantom tương tự như cấu trúc chuỗi khối hỗ trợ EVM và hợp đồng thông minh. Mặc dù Fantom có ​​tổng sản lượng đặt hàng, các nhà phát triển vẫn tìm cách tối ưu hóa Lớp 1 theo cơ chế đồng thuận DAG. Avalanche đã chọn một cách tiếp cận khác, tạo ra một cơ chế đồng thuận riêng Snowman để hỗ trợ sự phát triển thuận tiện của EVM và hợp đồng thông minh. IOTA cũng đã chọn một cách tiếp cận khác và đang tạo ra một khuôn khổ để cho phép dễ dàng triển khai các phiên bản chuỗi khối trên IOTA để hỗ trợ EVM, tạo ra một cơ sở hạ tầng Lớp 2 được sắp xếp đầy đủ một cách hiệu quả. Thiết kế độc đáo của Sui rất hứa hẹn. Các giao dịch có thể được sắp xếp đầy đủ hoặc sắp xếp nhân quả khi cần. Nó tương thích với các hợp đồng thông minh và có thể giảm độ trễ.

Sui là Lớp 1 dựa trên DAG mới nhất, nhưng Sui đã đạt được sự khác biệt và cải thiện các khiếm khuyết của kiến ​​trúc trước đó, vì vậy Sui đã nhận ra một cấu trúc giúp DAG thực sự là một sổ cái phân tán. Ngay cả khi các giao dịch nhân quả sẽ không trở thành xu hướng chủ đạo trong tương lai, công nghệ dựa trên DAG sẽ giúp mở rộng các chuỗi khối hiện có. Mặc dù DAG như một phương pháp mở rộng quy mô có thể không phải là lựa chọn tốt nhất cho mọi trường hợp sử dụng, nhưng trên X-Chain và IOTA của Avalanche, DAG dường như hoạt động tốt về độ trễ và thông lượng.

tiêu đề phụ

Giới thiệu về tác giả

từ chối trách nhiệm

từ chối trách nhiệm

Thông tin trong tài liệu này (“Thông tin”) chỉ được cung cấp cho mục đích thông tin, ở dạng tóm tắt và không đầy đủ. Những tài liệu này không phải và không nhằm mục đích trở thành một đề nghị hoặc chào mời một đề nghị bán hoặc mua bất kỳ chứng khoán hoặc sản phẩm nào. Những thông tin như vậy không được cung cấp và không nên được coi là cung cấp lời khuyên đầu tư.

liên kết gốc

liên kết gốc