Quét để tải ứng dụng Gate
qrCode
Thêm tùy chọn tải xuống
Không cần nhắc lại hôm nay

Khả năng không thể đạt được sự công bằng hoàn hảo trong việc sắp xếp giao dịch

https://img-cdn.gateio.im/webp-social/pixel?postId=228649®ionId=1.webp

Trong nhiều thập kỷ, nghiên cứu về hệ thống phân tán, đặc biệt là trong đồng thuận Byzantine và sao chép máy trạng thái (SMR), đã tập trung vào hai mục tiêu chính: tính nhất quán và khả năng sống còn. Tính nhất quán có nghĩa là tất cả các nút đồng ý về cùng một trình tự các giao dịch, trong khi khả năng sống còn đảm bảo hệ thống tiếp tục thêm các giao dịch mới. Tuy nhiên, các đặc tính này không ngăn cản các tác nhân xấu thay đổi thứ tự các giao dịch sau khi chúng đã được nhận.

Trong các blockchain công khai, khoảng trống trong các đảm bảo đồng thuận truyền thống đã trở thành một vấn đề nghiêm trọng. Các validator, nhà xây dựng khối hoặc người sắp xếp có thể lợi dụng vai trò đặc quyền của họ trong việc sắp xếp khối để thu lợi tài chính, gọi là giá trị khai thác tối đa (MEV). Thao tác này bao gồm việc đặt trước có lợi nhuận, thao túng phía sau và chèn các giao dịch vào giữa. Bởi vì thứ tự thực thi giao dịch quyết định tính hợp lệ hoặc lợi nhuận trong các ứng dụng DeFi, tính toàn vẹn của thứ tự giao dịch là rất quan trọng để duy trì công bằng và niềm tin.

Để giải quyết khoảng trống bảo mật quan trọng này, công bằng thứ tự giao dịch đã được đề xuất như một đặc tính đồng thuận thứ ba thiết yếu. Các giao thức công bằng thứ tự đảm bảo rằng thứ tự cuối cùng của các giao dịch phụ thuộc vào các yếu tố bên ngoài, khách quan, chẳng hạn như thời gian đến (hoặc thứ tự nhận) và có khả năng chống lại việc sắp xếp lại trái phép. Bằng cách giới hạn quyền lực của người đề xuất khối trong việc sắp xếp lại các giao dịch, các giao thức này giúp các blockchain trở nên minh bạch hơn, dự đoán được hơn và chống MEV.

Nghịch lý Condorcet và sự không thể đạt được công bằng lý tưởng

Khái niệm rõ ràng và mạnh mẽ nhất về công bằng là Công bằng theo thứ tự nhận (ROF). Được định nghĩa một cách không chính thức là “nhận đầu tiên, xuất ra đầu tiên,” ROF quy định rằng nếu một số lượng đủ lớn các giao dịch (tx) đến sớm hơn một giao dịch (tx′) thì hệ thống phải sắp xếp tx trước tx′ để thực thi.

Tuy nhiên, việc đạt được “công bằng theo thứ tự” này một cách phổ quát là không thể trừ khi giả định rằng tất cả các nút có thể giao tiếp tức thì (tức là hoạt động trong một mạng bên ngoài đồng bộ tức thì). Kết quả không thể này bắt nguồn từ một mối liên hệ bất ngờ với lý thuyết lựa chọn xã hội, cụ thể là nghịch lý Condorcet.

Nghịch lý Condorcet minh họa cách mà, ngay cả khi mỗi nút cá nhân duy trì một thứ tự nội bộ chuyển tiếp của các giao dịch, sở thích tập thể qua hệ thống có thể tạo thành các chu kỳ không chuyển tiếp. Ví dụ, có thể một đa số các nút nhận A trước B, đa số nhận B trước C, và đa số nhận C trước A. Do đó, ba sở thích đa số này tạo thành một vòng (ABCA). Điều này có nghĩa là không thể có một thứ tự nhất quán duy nhất của các giao dịch A, B và C thỏa mãn tất cả sở thích đa số cùng lúc.

Nghịch lý này chứng minh lý do tại sao mục tiêu đạt được hoàn hảo Công bằng theo thứ tự nhận là không thể trong các mạng bất đồng bộ, hoặc thậm chí trong các mạng đồng bộ chia sẻ đồng hồ chung nếu độ trễ của mạng bên ngoài quá lớn. Điều này đòi hỏi phải chấp nhận các định nghĩa công bằng yếu hơn, chẳng hạn như công bằng theo lô hàng.

Hedera Hashgraph và điểm yếu của timestamp trung vị

Hedera, sử dụng thuật toán đồng thuận Hashgraph, cố gắng xấp xỉ một khái niệm mạnh về công bằng theo thứ tự nhận (ROF). Nó làm điều này bằng cách gán cho mỗi giao dịch một timestamp cuối cùng được tính bằng trung vị của tất cả các timestamp cục bộ của các nút đối với giao dịch đó.

Tuy nhiên, phương pháp này vốn dĩ dễ bị thao túng. Một nút đối nghịch có thể cố ý làm sai lệch timestamp cục bộ của mình và đảo ngược thứ tự cuối cùng của hai giao dịch, ngay cả khi tất cả các thành viên trung thực nhận chúng theo đúng thứ tự.

Xem xét một ví dụ đơn giản với năm nút đồng thuận (A, B, C, D và E), trong đó Nút E hành xử độc ác. Hai giao dịch, tx₁ và tx₂, được phát sóng ra mạng. Tất cả các nút trung thực nhận tx₁ trước tx₂, do đó thứ tự cuối cùng dự kiến là tx₁ → tx₂.

In trong ví dụ này, kẻ tấn công gán cho tx₁ timestamp muộn hơn (3) và tx₂ sớm hơn (2) để làm lệch trung vị.

Khi thuật toán tính trung vị:

  • Đối với tx₁, các timestamp (1, 1, 4, 4, 3) cho ra trung vị là 3.
  • Đối với tx₂, các timestamp (2, 2, 5, 5, 2) cho ra trung vị là 2.

Vì timestamp cuối cùng của tx₁ (3) lớn hơn của tx₂ (2), thuật toán sẽ xuất ra thứ tự tx₂ → tx₁, đảo ngược thứ tự thực tế mà tất cả các nút trung thực đã quan sát.

Ví dụ này cho thấy một điểm yếu nghiêm trọng: Hàm trung vị, mặc dù trông trung lập, lại chính là nguyên nhân gây ra sự không công bằng vì nó có thể bị khai thác bởi một thành viên gian lận để điều chỉnh thứ tự cuối cùng của các giao dịch.

Do đó, việc timestamp trung vị của Hashgraph, vốn thường được ca ngợi là công bằng, lại là một khái niệm yếu về công bằng. Thuật toán Hashgraph không đảm bảo công bằng theo thứ tự nhận và thay vào đó phụ thuộc vào tập hợp validator có phép, chứ không dựa trên các đảm bảo mật mã.

Đạt được các đảm bảo thực tế

Tuy nhiên, để vượt qua sự không thể lý thuyết do Condorcet chứng minh, các scheme công bằng thực tế phải điều chỉnh lại định nghĩa về công bằng theo một cách nào đó.

Các giao thức Aequitas đã giới thiệu tiêu chí Công bằng theo thứ tự khối (BOF), hay công bằng theo lô hàng. BOF quy định rằng nếu đủ nhiều nút nhận một giao dịch tx trước một giao dịch tx′, thì tx phải được đưa vào trong một khối trước hoặc cùng lúc với tx′, nghĩa là không nút trung thực nào có thể đưa tx′ vào trong khối sau tx. Điều này làm yếu đi quy tắc từ “phải được giao sau” (ROF) thành “phải được giao không muộn hơn”.

Xem xét ba nút đồng thuận (A, B và C) và ba giao dịch: tx₁, tx₂, và tx₃. Một giao dịch được coi là “nhận sớm hơn” nếu ít nhất hai trong ba nút (đồng thuận) quan sát thấy nó đầu tiên.

If chúng ta áp dụng bỏ phiếu đa số để xác định thứ tự toàn cầu:

  • tx₁ → tx₂ (được A và C đồng thuận)
  • tx₂ → tx₃ (được A và B đồng thuận)
  • tx₃ → tx₁ (được B và C đồng thuận)

Những sở thích này tạo thành một vòng: tx₁ → tx₂ → tx₃ → tx₁. Trong tình huống này, không thể có một thứ tự duy nhất thỏa mãn tất cả mọi người cùng lúc, điều này có nghĩa là công bằng theo ROF chặt chẽ là không thể đạt được.

BOF giải quyết bằng cách nhóm tất cả các giao dịch mâu thuẫn vào cùng một lô hoặc khối thay vì ép buộc một giao dịch phải đến trước. Thuật toán đơn giản xuất ra:

Khối B₁ = {tx₁, tx₂, tx₃}

Điều này có nghĩa là, từ góc nhìn của giao thức, cả ba giao dịch đều được xử lý như thể chúng xảy ra cùng lúc. Trong khối, một phương pháp phân định thứ tự chính xác (như một giá trị băm) quyết định thứ tự thực thi chính xác. Bằng cách này, BOF đảm bảo tính công bằng cho từng cặp giao dịch và giữ cho nhật ký giao dịch cuối cùng nhất quán cho tất cả mọi người. Mỗi giao dịch được xử lý không muộn hơn giao dịch đi trước nó.

Điều chỉnh nhỏ nhưng quan trọng này cho phép giao thức xử lý các tình huống khi thứ tự giao dịch mâu thuẫn, bằng cách nhóm các giao dịch mâu thuẫn đó vào cùng một khối hoặc lô. Điều này không dẫn đến một thứ tự phần, vì mỗi nút vẫn phải đồng thuận về một trình tự tuyến tính duy nhất của các giao dịch. Các giao dịch trong mỗi khối vẫn được sắp xếp theo thứ tự cố định để thực thi. Trong các trường hợp không có mâu thuẫn, giao thức vẫn đạt được đặc tính mạnh hơn của ROF.

Dù Aequitas đã thành công trong việc đạt được BOF, nhưng nó gặp phải những hạn chế đáng kể, đặc biệt là độ phức tạp giao tiếp rất cao và chỉ có thể đảm bảo khả năng sống còn yếu. Khả năng sống còn yếu có nghĩa là việc giao dịch được giao sau chỉ được đảm bảo sau khi chu trình Condorcet mà nó tham gia đã hoàn tất. Điều này có thể mất thời gian vô hạn nếu các chu trình “xếp chồng” lên nhau.

Giao thức Themis được giới thiệu để thực thi cùng một đặc tính BOF mạnh mẽ hơn, nhưng với độ phức tạp giao tiếp được cải thiện. Themis đạt được điều này bằng ba kỹ thuật: Gỡ bỏ lô hàng theo từng đợt, Đặt hàng trì hoãn và Các đảm bảo trong lô mạnh mẽ hơn.

Trong dạng tiêu chuẩn, Themis yêu cầu mỗi thành viên trao đổi tin nhắn với hầu hết các nút khác trong mạng. Lượng giao tiếp cần thiết tăng theo bình phương số lượng thành viên mạng. Tuy nhiên, trong phiên bản tối ưu, SNARK-Themis, các nút sử dụng các chứng minh mật mã ngắn gọn để xác minh tính công bằng mà không cần giao tiếp trực tiếp với tất cả các thành viên khác. Điều này giảm tải giao tiếp sao cho chỉ tăng tuyến tính, giúp Themis mở rộng hiệu quả ngay cả trong các mạng lớn.

Giả sử có năm nút (A–E) tham gia đồng thuận nhận ba giao dịch: tx₁, tx₂, và tx₃. Do độ trễ mạng, thứ tự cục bộ của chúng khác nhau:

As trong Aequitas, những sở thích này tạo thành một chu trình Condorcet. Nhưng thay vì chờ đợi toàn bộ chu trình được giải quyết, Themis giữ cho hệ thống hoạt động bằng phương pháp gọi là gỡ bỏ lô hàng theo từng đợt. Nó xác định tất cả các giao dịch nằm trong chu trình và nhóm chúng thành một tập hợp, gọi là thành phần liên kết mạnh (SCC). Trong trường hợp này, tất cả ba giao dịch thuộc cùng một SCC, mà Themis xuất ra dưới dạng một lô đang xử lý, gọi là Lô B₁ = {tx₁, tx₂, tx₃}.

Bằng cách này, Themis cho phép mạng tiếp tục xử lý các giao dịch mới ngay cả khi thứ tự nội bộ của Lô B₁ vẫn đang được hoàn thiện. Điều này đảm bảo hệ thống luôn hoạt động và tránh bị đình trệ.

Tổng quan:

Khái niệm công bằng hoàn hảo trong thứ tự giao dịch có vẻ đơn giản. Ai gửi giao dịch đến mạng đầu tiên sẽ được xử lý trước. Tuy nhiên, như nghịch lý Condorcet chứng minh, lý tưởng này không thể tồn tại trong các hệ thống phân tán thực tế. Các nút khác nhau thấy các giao dịch theo thứ tự khác nhau, và khi các quan điểm đó mâu thuẫn, không có giao thức nào có thể xây dựng một trình tự “đúng” duy nhất mà không phải thỏa hiệp.

Hashgraph của Hedera cố gắng xấp xỉ lý tưởng này với timestamp trung vị, nhưng phương pháp đó dựa nhiều vào niềm tin hơn là bằng chứng. Một thành viên gian lận có thể làm sai lệch trung vị và đảo ngược thứ tự giao dịch, cho thấy rằng “timestamp công bằng” không thực sự công bằng.

Các giao thức như Aequitas và Themis tiến xa hơn bằng cách thừa nhận những gì có thể và không thể đạt được. Thay vì theo đuổi điều không thể, họ định nghĩa lại công bằng theo cách vẫn giữ được tính toàn vẹn thứ tự trong điều kiện mạng thực tế. Điều này không phải là từ chối công bằng, mà là sự tiến hóa của nó. Sự tiến hóa này phân định rõ ràng giữa công bằng cảm nhận và công bằng có thể chứng minh. Nó cho thấy rằng tính toàn vẹn thứ tự giao dịch thực sự trong hệ thống phi tập trung không thể dựa vào uy tín, niềm tin validator hay kiểm soát có phép. Nó phải đến từ xác minh mật mã tích hợp trong chính giao thức.

Bài viết này không đưa ra lời khuyên đầu tư hoặc đề xuất nào. Mọi hoạt động đầu tư và giao dịch đều mang rủi ro, và độc giả nên tự nghiên cứu khi đưa ra quyết định.

Bài viết mang tính thông tin chung và không nhằm mục đích là lời khuyên pháp lý hoặc đầu tư. Các quan điểm, suy nghĩ và ý kiến trình bày ở đây là của tác giả và không nhất thiết phản ánh quan điểm của Cointelegraph.

Cointelegraph không bảo trợ nội dung của bài viết này cũng như bất kỳ sản phẩm nào được đề cập. Độc giả nên tự nghiên cứu trước khi thực hiện bất kỳ hành động nào liên quan đến bất kỳ sản phẩm hoặc công ty nào được đề cập và chịu trách nhiệm hoàn toàn về quyết định của mình.

IN1.65%
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
  • Phần thưởng
  • Bình luận
  • Đăng lại
  • Retweed
Bình luận
0/400
Không có bình luận
  • Gate Fun hotXem thêm
  • Vốn hóa:$4.25KNgười nắm giữ:1
    0.00%
  • Vốn hóa:$4.23KNgười nắm giữ:1
    0.00%
  • Vốn hóa:$4.22KNgười nắm giữ:1
    0.00%
  • Vốn hóa:$4.21KNgười nắm giữ:1
    0.00%
  • Vốn hóa:$4.21KNgười nắm giữ:1
    0.00%
  • Ghim
Giao dịch tiền điện tử mọi lúc mọi nơi
qrCode
Quét để tải xuống ứng dụng Gate
Cộng đồng
Tiếng Việt
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)