Cho đến nay, huyền thoại về phúc lợi trong vòng tròn tiền tệ/ngành công nghiệp blockchain vẫn tiếp tục và lĩnh vực quan trọng tiếp theo của việc “tạo ra sự giàu có” là tập trung vào “đường đua”. Dự án XAI đang tổ chức một sự kiện Odyssey. Nếu bạn quan tâm, vui lòng tham gia bài viết này của tôi trên quảng trường: Hướng dẫn không tốn chi phí cho sự kiện Odyssey của chuỗi trò chơi XAI
Trong bài viết này, tôi sẽ mang đến cho bạn lời giải thích chi tiết về nút Sentry của chuỗi công khai trò chơi XAI! Bài viết này mang tính kỹ thuật tương đối nên nếu bạn quan tâm đến việc kiếm tiền thì phải đọc kỹ. Bởi chỉ khi tự mình hiểu được “logic” và nâng cao nhận thức thì bạn mới có cơ hội kiếm tiền!
Nếu bạn muốn xem trực tiếp về nút Sentry, hãy đọc trực tiếp phần đầu tiên mà không cần đọc sau; nếu bạn muốn có một vòng lặp logic khép kín thì bạn cần đọc phần thứ hai, thứ ba và thứ tư!
Điều tôi muốn nhấn mạnh là Xai nhận được hỗ trợ kỹ thuật trực tiếp từ Offchain Labs. Loại hỗ trợ này là điều không thể tưởng tượng được đối với các chuỗi Orbit khác! và là thành phần quan trọng trong kế hoạch trò chơi chiến lược của Xai trong hệ sinh thái Arbitrum.
Phần 1: Giải thích về nút Sentry
Nút Sentry là nút quan sát giám sát giao thức cuộn lên Xai và nếu một khối xấu được đề xuất, nó sẽ phát ra âm thanh cảnh báo (bằng bất kỳ phương tiện nào mà nhà điều hành nó chọn) để người khác có thể can thiệp. Mục đích của nút canh gác là để giải quyết tình huống khó xử của người xác minh (xem Phần IV để biết chi tiết về tình huống khó xử của người xác minh).
Bấm vào đây để xem video quảng cáo:
Quảng cáo video nút trọng điểm
Chạy các nút Xai và nhận mã thông báo Xai chỉ bằng một cú nhấp chuột!
Các nút Sentinel có thể chạy trên máy tính xách tay, máy tính để bàn hoặc thậm chí trên đám mây của các thành viên cộng đồng. Miễn là nút đang chạy, sẽ có một thuật toán xác suất xác định liệu nhà điều hành nút có được thưởng bằng mã thông báo esXai từ mạng hay không. Bằng cách đặt cược Xai, bạn sẽ tăng xác suất của thuật toán. Nếu bạn chưa biết về esXai, vui lòng tham gia bài viết của tôi trên Square: Giải thích về “Nền kinh tế mã thông báo” của dự án XAI
1. Nguyên lý hoạt động của nút canh gác
Giao thức Thử thách chú ý v2 bao gồm nhiều người tham gia, bao gồm chuỗi Xai, chuỗi chính (Arbitrum One), người thách thức đáng tin cậy, người canh gác Xai và khóa cấp phép của họ cũng như hợp đồng Trọng tài (trọng tài). Người thách thức tạo cặp khóa BLS, đăng ký khóa chung cho hợp đồng trọng tài và ký các xác nhận quyền sở hữu của người xác nhận trong giao thức tổng hợp Xai trên Arbitrum One. Những chữ ký này được xác minh bằng hợp đồng trọng tài và được ghi lại dưới dạng những thách thức liên quan đến khiếu nại.
Xai Sentinels có thể đăng ký với hợp đồng trọng tài bằng cách mua mã cấp phép Sentinel để đủ điều kiện đưa ra tuyên bố về các khiếu nại. Họ lấy trạng thái gốc của câu lệnh chính xác sẽ là phần kế thừa của câu lệnh phát hành. Nếu một điều kiện nhất định được đáp ứng, họ sẽ đưa ra tuyên bố về tuyên bố đó bằng cách viện dẫn hợp đồng trọng tài. Nếu tuyên bố tiếp theo được tạo và xác nhận và Sentinel đưa ra tuyên bố chính xác, Sentinel sẽ liên hệ với hợp đồng trọng tài để thực hiện giao dịch quy đổi. Trọng tài sẽ xác minh một số điều kiện trước khi trả phần thưởng cho Sentinel.
Giao thức này đảm bảo rằng mỗi xác nhận quyền sở hữu phải sử dụng đầy đủ các tin nhắn trong hộp thư đến tồn tại khi xác nhận quyền sở hữu trước đó được tạo. Điều này có nghĩa là sau khi một xác nhận quyền sở hữu được tạo, gốc trạng thái của các xác nhận quyền sở hữu chính xác tiếp theo của nó sẽ được xác định đầy đủ và có thể được tính toán bởi bất kỳ nút nào. Điều này khuyến khích mỗi trọng điểm xác định gốc trạng thái tiếp theo chính xác. Phần thưởng của lính canh được xác định bởi ID cấp phép trạng thái của lính canh, gốc trạng thái tiếp theo và giá trị thử thách không được biết cho đến khi gốc trạng thái tiếp theo được xác định đầy đủ.
2. Ai có thể chạy nút?
Bất cứ ai cũng có thể vận hành Sentinel bằng cách tải xuống phần mềm, cài đặt và chạy nó. Tuy nhiên, để nhận được phần thưởng mã thông báo, bạn phải mua ít nhất một khóa cấp phép Sentinel.
Người mua phải vượt qua kiểm tra KYC thành công để đảm bảo họ:
không phải ở Hoa Kỳ
Không chịu bất kỳ lệnh trừng phạt OFAC nào của Hoa Kỳ (OFAC được phản ánh trong danh sách trừng phạt của Hoa Kỳ)
Những nút Sentinel không hoạt động hoặc không có đủ tiền để trả phí gas (GAS) sẽ không tích lũy phần thưởng, ngay cả khi có khóa cấp phép. Do đó, các nhà khai thác sẽ muốn đảm bảo rằng các nút của họ được tài trợ, trực tuyến và đang chạy.
3. Hợp đồng trọng tài (trọng tài)
Trọng tài là một hợp đồng thông minh được thiết kế để thực thi việc tuân thủ các quy tắc được xác định trước, xác minh nguồn gốc của bài gửi và phân phối phần thưởng cho người chiến thắng trong hệ thống. Hợp đồng thông minh trọng tài là một thành phần quan trọng trong hệ sinh thái Xai, chịu trách nhiệm quản lý và xác thực các khiếu nại được đưa ra bởi các nút trọng điểm trong mạng. Hợp đồng có một số chức năng chính:
3.1 Nộp tờ khai
Hợp đồng trọng tài cho phép các nút trọng điểm gửi yêu cầu đối với các thách thức. Chức năng này chỉ có thể được gọi bởi chủ sở hữu khóa cấp phép Sentinel hoặc địa chỉ được phê duyệt của họ trong hợp đồng này. Chức năng này kiểm tra xem thử thách có còn mở để gửi hay không và liệu Giấy phép Node đã được gửi cho thử thách này hay chưa.
3.2 Nhận phần thưởng
Hợp đồng có một tính năng cho phép người dùng nhận phần thưởng cho các yêu cầu thành công. Chức năng này kiểm tra xem thử thách đã được đóng để gửi hay chưa và kiểm tra xem chủ sở hữu khóa nút đã hoàn thành KYC hay chưa. Nếu những điều kiện này được đáp ứng và yêu cầu đủ điều kiện để thanh toán, phần thưởng sẽ được gửi đến người dùng.
3.3 Tạo hàm băm yêu cầu và kiểm tra thanh toán.
Hợp đồng có chức năng tạo ra hàm băm của ID quyền trọng điểm, ID thử thách, challengerSignedHash trong thử thách và trạng thái gốc tiếp theo. Sau đó, nó sẽ kiểm tra xem hàm băm có nằm dưới một ngưỡng nhất định hay không, được tính toán dựa trên tổng số giấy phép Sentinel đã được tạo ra. Nếu hàm băm dưới ngưỡng thì yêu cầu đó đủ điều kiện để thanh toán.
Hợp đồng trọng tài đảm bảo tính toàn vẹn của mạng Xai bằng cách xác thực các yêu cầu và khen thưởng những yêu cầu thành công, từ đó khuyến khích các nút trọng điểm giám sát mạng một cách chính xác và siêng năng.
4. Thành phần thách thức
Người thách thức là một thực thể đáng tin cậy trong hệ sinh thái Xai. Nó tạo ra một cặp khóa BLS và đăng ký khóa chung cho hợp đồng trọng tài. Khi người xác thực đưa ra yêu cầu trong giao thức tổng hợp Xai, người thách thức ký xác nhận quyền sở hữu bằng khóa riêng của mình và gửi chữ ký cho trọng tài. Trọng tài xác minh chữ ký và ghi lại nó như một thử thách liên quan đến tuyên bố. Quá trình này đảm bảo tính toàn vẹn của các xác nhận quyền sở hữu được đưa ra trong giao thức tổng hợp Xai.
5. Khóa (Quyền khóa nút Sentinel, dựa trên NFT)
Khóa cấp phép Sentinel là một mã thông báo duy nhất, không thể thay thế (NFT) được yêu cầu để vận hành nút Sentinel trong mạng Xai. Giấy phép Sentinel đóng vai trò là bằng chứng về tính đủ điều kiện để các nút gửi yêu cầu và nhận phần thưởng. Nó được đúc bằng cách gửi số lượng ETH chính xác và giá đúc được xác định bởi hệ thống ngưỡng tăng dần.
Cấp phép nút đóng một vai trò quan trọng trong hợp đồng trọng tài. Khi một nút muốn gửi yêu cầu cho một thử thách, nó phải cung cấp ID quyền Sentinel của mình. Hợp đồng trọng tài kiểm tra xem giấy phép Sentinel có hợp lệ hay không và liệu nút đó có phải là chủ sở hữu giấy phép Sentinel hay nhà điều hành được phê duyệt hay không (phần KYC ở trên). Nếu những điều kiện này được đáp ứng, yêu cầu của nút sẽ được gửi tới thử thách.
Các quyền của Sentinel cũng có hiệu lực khi yêu cầu phần thưởng cho các yêu cầu thành công. Hợp đồng trọng tài kiểm tra xem chủ sở hữu giấy phép Sentinel đã hoàn thành KYC hay chưa và liệu bản sao kê có đủ điều kiện để thanh toán hay không. Nếu những điều kiện này được đáp ứng, phần thưởng sẽ được gửi đến chủ sở hữu giấy phép Sentinel.
Tóm lại, quyền Sentinel là một thành phần quan trọng trong mạng Xai, mạng này quy định hoạt động của các nút Sentinel, gửi yêu cầu và phân phối phần thưởng.
6. Tải xuống và chạy nút
Để chạy một nút canh gác, người dùng chỉ cần tải xuống một gói phần mềm cụ thể. Gói này có thể được sử dụng trong ứng dụng máy tính để bàn hoặc dưới dạng công cụ dòng lệnh trên máy tính của bạn. Nói một cách đơn giản, những ứng dụng này là công cụ giúp phần mềm Sentinel dễ sử dụng hơn. Mục đích của gói này là tự động hóa tất cả các thao tác cần thiết để chạy Sentinel, giúp việc thiết lập và sử dụng rất đơn giản, ngay cả khi bạn không rành về kỹ thuật.
Bộ phần mềm này hỗ trợ người dùng thực hiện các công việc như thiết lập, quản lý, tương tác với các bộ phận khác, đồng thời có giao diện dễ sử dụng cho phép người dùng xem và điều chỉnh cài đặt một cách dễ dàng. Sử dụng gói này, người dùng có thể tập trung hơn vào cách chạy tốt hơn và nhận được nhiều phần thưởng token hơn. Người dùng có thể chọn chạy gói này bằng ứng dụng máy tính để bàn hoặc công cụ dòng lệnh, cả hai đều rất dễ sử dụng và giúp quá trình thao tác rất trơn tru.
7. Chức năng ví Sentinel
Trong hệ sinh thái Xai, ví Sentinel đóng vai trò quan trọng trong sự tương tác giữa các nút Sentinel và hợp đồng thông minh trọng tài. Ví Sentinel đóng vai trò là đại lý trung gian và chịu trách nhiệm gửi báo cáo cho trọng tài thay mặt cho các Sentinel có liên quan. Điều này đạt được thông qua các chức năng cụ thể trong hợp đồng trọng tài mà chỉ chủ sở hữu khóa cấp phép Sentinel hoặc địa chỉ được họ phê duyệt trong hợp đồng này mới có thể gọi.
Ví Sentinel có thể gửi tuyên bố cho thử thách bằng cách gọi hàm submitAssertionToChallenge trong hợp đồng trọng tài. Chức năng này kiểm tra xem thử thách có còn mở để gửi hay không và liệu khóa nút đã được gửi cho thử thách này hay chưa.
Ví Sentry cũng có thể nhận phần thưởng cho các yêu cầu thành công bằng cách gọi hàm ClaimReward trong hợp đồng trọng tài. Tính năng này kiểm tra xem thử thách đã được đóng để gửi hay chưa và kiểm tra xem chủ sở hữu giấy phép Sentinel đã hoàn tất quy trình kiểm tra "KYC" hay chưa. Nếu những điều kiện này được đáp ứng và yêu cầu đủ điều kiện để thanh toán, phần thưởng sẽ được gửi đến chủ sở hữu Sentinel.
Tóm lại, Ví Sentinel hoạt động như một người đưa tin, tạo điều kiện thuận lợi cho sự tương tác giữa các nút và trọng tài, từ đó đảm bảo mạng Xai hoạt động trơn tru.
8. Giấy phép
Mối quan hệ giữa số lượng giấy phép và khả năng gửi của nút là cơ bản. Mặc dù một nút có thể có nhiều giấy phép được liên kết với nó, nhưng điều quan trọng là phải nhận ra rằng số lượng giấy phép ảnh hưởng trực tiếp đến khả năng cam kết của nút đó. Về cơ bản, để đảm bảo hạn mức cam kết công bằng, tỷ lệ giấy phép trên các phiên bản nút được duy trì ở mức 1:1. Bằng cách tuân theo các nguyên tắc trên, hệ thống thiết lập một cách tiếp cận có cấu trúc để cấp phép, gửi quyền và hoạt động tổng thể của các nút trong hệ sinh thái.
9. Yêu cầu phần mềm và phần cứng của nút Sentry
Phần mềm nút Sentinel hỗ trợ máy tính để bàn Windows, Mac và Linux (yêu cầu 64-bit). Sau đây là các tài nguyên hiện tại cần thiết để chạy phần mềm nút Sentinel cho tối đa 100 khóa cấp phép:
RAM 4GB
2 lõi CPU
Dung lượng ổ đĩa 60 GB
Bộ xử lý x86/X64 (hỗ trợ bộ xử lý ARM, chẳng hạn như chip Apple M1/M2)
Kết nối internet ổn định
Khi thêm các khóa bổ sung vào một nút, lý tưởng nhất là khả năng phần cứng sẽ tăng tương ứng. Tuy nhiên, không bắt buộc phải gán máy riêng cho từng phím. Hệ thống này dự kiến sẽ có khả năng mở rộng để chứa hàng chục phím trên một máy và có thể nhiều hơn nữa.
Lưu ý: Những yêu cầu phần cứng này có thể thay đổi.
10. Phần thưởng mạng nút Sentry ước tính
Mô hình kinh tế mã thông báo XAI, vui lòng tham khảo: Giải thích về "Nền kinh tế mã thông báo" của dự án XAI
Dưới đây là ba tình huống để ước tính phần thưởng Xai mà bạn có thể kiếm được khi chạy nút Sentry. Ba kịch bản này dựa trên các giả định sau:
Tổng XAI và esXAI sẽ không bao giờ vượt quá 2.500.000.000. Do hệ sinh thái Xai rất năng động nên không thể dự đoán chính xác phần thưởng mã thông báo hàng tháng cho mỗi khóa Sentry.
100% GAS bị đốt cháy nên không có gì đảm bảo nguồn cung sẽ luôn lạm phát, có thể là giảm phát.
Xai Foundation sẽ không bán quá 50.000 khóa Sentry (một nút có thể tải nhiều khóa). Dự kiến việc này sẽ mất 2-3 năm. Chìa khóa canh gác sẽ đắt hơn theo thời gian.
Số tiền esXAI hàng tháng cho mỗi khóa Sentry cũng có thể dao động dựa trên số lượng người tham gia đặt cược trong hệ sinh thái.
Ý nghĩa của ba bảng sau đây là dưới sự lưu hành khác nhau của mã thông báo XAI và esXAI, số lượng khóa nút được kích hoạt trong mạng và phần thưởng mã thông báo hàng tháng dự kiến tương ứng cho mỗi khóa:
Kịch bản Ước tính: Nếu có tổng cộng 750.000 mã thông báo XAI và esXAI đang lưu hành thì mỗi khóa Sentry sẽ nhận được phần thưởng esXAI theo bảng sau:
Ước tính kịch bản B: Nếu có tổng cộng 1.250.000.000 mã thông báo XAI và esXAI đang lưu hành thì mỗi khóa Sentry sẽ nhận được phần thưởng esXAI theo bảng sau:
Ước tính Kịch bản C: Nếu có tổng cộng 2.187.500.000 mã thông báo XAI và esXAI đang lưu hành thì mỗi khóa Sentry sẽ nhận được phần thưởng esXAI theo bảng sau:
Phần 2: XAI được phát triển và duy trì bởi Arbitrum (ARB), vì vậy chúng ta phải làm sáng tỏ kiến trúc của Arbitrum:
1.Quyết định Nitro
Tất cả các chuỗi Arbitrum đều được xây dựng trên Arbitrum Nitro, đây là công nghệ cơ bản cho tất cả các chuỗi trong hệ sinh thái. Nitro chạy một phiên bản phân nhánh của Geth và sử dụng WebAssugging làm máy ảo cơ bản chống gian lận.
2.Quyết định ủy thác bất kỳ
Anytrust là giao thức Arbitrum quản lý tính khả dụng của dữ liệu thông qua một nhóm người cấp phép được gọi là Ủy ban sẵn có dữ liệu (DAC). Giao thức này giảm phí giao dịch bằng cách đưa ra một giả định tin cậy bổ sung về tính khả dụng của dữ liệu, thay vì sử dụng cơ chế sẵn có dữ liệu không đáng tin cậy của Ethereum.
3. Giới thiệu về Arbitrum 2 lớp có thể bạn đã biết
Arbitrum Nova là một ví dụ về chuỗi AnyTrust; Arbitrum One là một chuỗi thay thế khác triển khai giao thức Arbitrum Rollup hoàn toàn không cần tin cậy (và sử dụng nhiều L1-gas hơn). Cả hai chuỗi đều được xây dựng trên Nitro.
4. Chuỗi quỹ đạo
Arbitrum Orbit cho phép các bên thứ ba tạo chuỗi Arbitrum Rollup và AnyTrust tự quản lý của riêng họ. Arbitrum cung cấp công nghệ Rollup và AnyTrust để mang lại sự linh hoạt tối đa khi xây dựng chuỗi Orbit. Giống như tất cả các chuỗi trong hệ sinh thái Arbitrum, cả chuỗi Arbitrum Rollups và chuỗi Arbitrum Anytrust Orbit đều được xây dựng bằng cách sử dụng Nitro làm công nghệ cơ bản.
5. Nắm rõ tình hình cơ bản của Xai
Hãy cùng hiểu Xai trong bối cảnh trên. Xai hoạt động như một chuỗi Arbitrum Orbit, tận dụng công nghệ Anytrust để có tốc độ tối đa và chi phí tối thiểu. Không giống như hầu hết các chuỗi Orbit “tự quản lý”, Xai được hưởng lợi từ sự hỗ trợ kỹ thuật trực tiếp từ Offchain Labs. Loại hỗ trợ này là điều không thể tưởng tượng được đối với các chuỗi Orbit khác! và là thành phần quan trọng trong kế hoạch trò chơi chiến lược của Xai trong hệ sinh thái Arbitrum.
Phần 3: Sau khi đã nắm được các khái niệm trên, hãy cùng tìm hiểu sâu hơn về kiến trúc:
1.AnyTrust: Cơ sở hạ tầng Blockchain mang tính cách mạng
Trong khuôn khổ AnyTrust và là một biến thể tiên tiến của công nghệ Arbitrum Nitro, Offchain Labs thúc đẩy sự đổi mới để giải quyết một số thách thức cấp bách nhất trong không gian blockchain. AnyTrust mang đến cho chúng ta một góc nhìn mới bằng cách kết hợp các giả định về độ tin cậy thấp, giảm đáng kể chi phí trong khi vẫn đảm bảo tính sẵn có và bảo mật dữ liệu mạnh mẽ.
2. Giảm chi phí thông qua giả định về niềm tin
Cốt lõi của giao thức Arbitrum, tất cả các nút Arbitrum (bao gồm cả người xác thực xác minh tính chính xác của chuỗi và đưa ra kết quả chính xác) cần truy cập dữ liệu của mọi giao dịch lớp hai (L2) trong hộp thư đến của chuỗi Arbitrum. Theo truyền thống, việc tổng hợp Arbitrum đảm bảo quyền truy cập dữ liệu bằng cách xuất bản dữ liệu dưới dạng calldata trên Ethereum lớp một (L1), một quá trình tạo ra phí gas Ethereum đáng kể, đây là một thành phần chi phí chính trong Arbitrum.
3.Ketsets Tính linh hoạt
Ketsets đóng vai trò quan trọng trong kiến trúc của AnyTrust. Họ chỉ định khóa chung của các thành viên ủy ban và số chữ ký cần thiết để xác minh Chứng chỉ sẵn có dữ liệu (DACert). Ketsets cung cấp sự linh hoạt cho việc thay đổi thành viên ủy ban và cho phép các thành viên ủy ban cập nhật khóa của họ khi cần.
4. Chứng chỉ sẵn có dữ liệu (DACerts)
Trong AnyTrust, khái niệm cơ bản là chứng chỉ sẵn có của dữ liệu (DACert). DACert bao gồm hàm băm của khối dữ liệu, thời gian hết hạn và bằng chứng cho thấy các thành viên ủy ban N-1 đã ký cặp (băm, thời gian hết hạn). Bằng chứng này bao gồm hàm băm của bộ khóa được sử dụng cho chữ ký, một bitmap cho biết thành viên ủy ban nào đã ký và chữ ký tổng hợp BLS trên đường cong BLS12-381, chứng minh người ký.
Do giả định độ tin cậy 2 trên N, DACert đóng vai trò là bằng chứng cho thấy dữ liệu của khối sẽ có sẵn cho ít nhất một thành viên ủy ban trung thực cho đến thời gian hết hạn được chỉ định. Giả định về độ tin cậy này là cơ sở cho độ tin cậy và tính bảo mật của tính sẵn có của dữ liệu trong khuôn khổ AnyTrust.
5. Cơ chế giải phóng dữ liệu kép
AnyTrust giới thiệu một phương pháp xuất bản khối dữ liệu kép trên L1. Ngoài phương pháp truyền thống là xuất bản các khối dữ liệu hoàn chỉnh, nó còn cho phép cấp DACerts, là các chứng chỉ chứng minh tính sẵn có của dữ liệu. Hợp đồng hộp thư đến L1 xác minh tính hợp lệ của DACert, bao gồm cả việc tham chiếu đến Keset hợp lệ được chỉ định trong DACert.
Mã L2 chịu trách nhiệm đọc dữ liệu từ hộp thư đến được thiết kế để xử lý liền mạch cả hai định dạng dữ liệu. Khi gặp DACert, nó sẽ thực hiện kiểm tra tính hợp lệ, bao gồm đảm bảo rằng số lượng người ký đáp ứng yêu cầu của Ketsets, xác thực chữ ký tổng hợp và xác nhận hết hạn ngoài dấu thời gian L2 hiện tại. DACerts hợp lệ đảm bảo rằng khối dữ liệu có thể truy cập được và có thể khai thác bằng mã L2.
6. Máy chủ sẵn có dữ liệu (DAS)
Các thành viên ủy ban vận hành Máy chủ sẵn có dữ liệu (DAS), cung cấp hai API chính:
(1) API bộ sắp xếp: Được thiết kế để bộ sắp xếp của chuỗi Arbitrum sử dụng, giao diện JSON-RPC này cho phép bộ sắp xếp gửi các khối dữ liệu tới DAS để lưu trữ.
(2) API REST: Được thiết kế để có khả năng truy cập rộng hơn, giao thức dựa trên RESTful HTTP(S) cho phép truy xuất các khối dữ liệu thông qua hàm băm. Nó hoàn toàn có thể lưu vào bộ nhớ đệm và có thể được triển khai cùng với proxy bộ nhớ đệm hoặc CDN để nâng cao khả năng mở rộng và bảo vệ khỏi các cuộc tấn công DoS tiềm ẩn.
7. Tương tác giữa người phân loại và ủy ban
Khi bộ phân loại Trọng tài dự định xuất bản một loạt dữ liệu thông qua ủy ban, nó sẽ gửi dữ liệu và thời gian hết hạn song song cho tất cả các thành viên ủy ban thông qua RPC. Mỗi thành viên ủy ban lưu trữ dữ liệu, ký vào cặp (băm, thời gian hết hạn) bằng khóa BLS của nó và trả về chữ ký và chỉ báo thành công cho trình sắp xếp thứ tự. Sau khi thu thập đủ chữ ký, trình sắp xếp chuỗi sẽ tổng hợp chúng để tạo ra một DACert hợp lệ cho các cặp (băm, thời gian hết hạn). DACert này sau đó được xuất bản vào hợp đồng hộp thư đến L1, giúp phần mềm chuỗi AnyTrust của L2 có thể truy cập được. Trong trường hợp trình sắp xếp chuỗi không thể thu thập đủ chữ ký trong khung thời gian đã chỉ định, nó sẽ áp dụng chiến lược "dự phòng để tổng hợp" và xuất bản dữ liệu hoàn chỉnh trực tiếp lên chuỗi L1. Phần mềm L2 vượt trội trong việc hiểu cả hai định dạng xuất bản dữ liệu (thông qua DACert hoặc dữ liệu hoàn chỉnh) và xử lý từng định dạng một cách thích hợp. Tóm lại, AnyTrust, với tư cách là một sự đổi mới đột phá trong hệ sinh thái Offchain Labs, thể hiện một tiến bộ quan trọng trong việc giải quyết tính sẵn có của dữ liệu, bảo mật và hiệu quả chi phí của cơ sở hạ tầng blockchain. Thông qua giả định tin cậy hợp lý và cách tiếp cận mới để xuất bản dữ liệu, AnyTrust mở đường cho các giải pháp blockchain an toàn, dễ tiếp cận và có thể mở rộng hơn.
Phần 4: Với các khái niệm trên, bây giờ chúng ta hãy giải thích tại sao các nút canh gác lại quan trọng: vấn đề kiểm tra gian lận, tại sao tình thế tiến thoái lưỡng nan của người xác nhận lại khó hơn bạn nghĩ và giải pháp!
Tác giả là Ed Felten, nhà khoa học trưởng tại Arbitrum
Trong các hệ thống blockchain, một mẫu thiết kế phổ biến là yêu cầu một bên thực hiện một số công việc và ký quỹ cho hành vi đúng, sau đó mời những người khác xác minh công việc và lấy đi khoản tiền đặt cọc này nếu họ phát hiện ra người lao động gian lận. Bạn có thể gọi nó là mẫu thiết kế "khẳng định-thách thức". Chúng tôi thực hiện việc này trong Arbitrum và gần đây đã thấy các đề xuất như Tổng hợp lạc quan.
Các hệ thống này có thể bị ảnh hưởng bởi tình thế tiến thoái lưỡng nan của người xác nhận, về cơ bản là nhận xét rằng chẳng ích gì khi kiểm tra công việc của ai đó nếu bạn biết họ sẽ không gian lận; nhưng nếu bạn không kiểm tra, họ sẽ có động cơ để gian lận. Nếu bạn là một nhà thiết kế, bạn muốn chứng minh rằng hệ thống của bạn tương thích với khuyến khích, nghĩa là nếu mọi người hành xử nhất quán với khuyến khích của họ thì sẽ không có gian lận xảy ra. Đây là lĩnh vực mà trực giác có thể dẫn bạn đi sai hướng. Vấn đề này khó khăn hơn nhiều so với vẻ ngoài của nó, như chúng ta sẽ thấy khi xem xét các động cơ khuyến khích của các bên dưới đây.
Một mô hình siêu đơn giản
Chúng tôi bắt đầu bằng cách xây dựng mô hình đơn giản nhất có thể. Giả sử có hai người chơi. Người khẳng định đưa ra một tuyên bố, có thể đúng hoặc sai. Người kiểm tra có thể kiểm tra tuyên bố của người khẳng định hoặc người kiểm tra có thể chọn không làm gì, có lẽ dựa trên giả định rằng người khẳng định có thể đang nói sự thật. Chúng tôi giả định rằng chi phí kiểm tra của người kiểm tra là C. Nếu người kiểm tra kiểm tra và phát hiện ra rằng người kiểm tra đã gian lận thì người kiểm tra sẽ nhận được phần thưởng là R. (R bao gồm tất cả các lợi ích mà người kiểm tra nhận được khi phát hiện gian lận. Điều này bao gồm các lợi ích nhận được "bên ngoài hệ thống" cũng như bất kỳ lợi ích nào có được do sự tin cậy ngày càng tăng đối với hệ thống.) Nếu người khẳng định không bị bắt, Khi gian lận, người kiểm tra sẽ thua L, chẳng hạn vì người khẳng định gian lận có thể lừa đảo lấy những món đồ có giá trị từ người kiểm tra.
Bây giờ chúng ta có hai mối đe dọa cần lo lắng: hối lộ và lười biếng. Hối lộ là khả năng người khẳng định có thể hối lộ người kiểm tra để không kiểm tra, từ đó cho phép người khẳng định gian lận mà không bị phát hiện. Chúng tôi có thể ngăn điều này xảy ra bằng cách đảm bảo rằng người xác nhận ký quỹ một khoản tiền gửi rất lớn lớn hơn tổng giá trị trong hệ thống và trả cho người kiểm tra khi phát hiện gian lận, để người xác nhận không sẵn sàng trả lớn hơn phần thưởng của người kiểm tra R mua chuộc. Điều này sẽ ngăn chặn hối lộ, nhưng nó đòi hỏi hệ thống phải được thế chấp hoàn toàn, điều này có thể rất tốn kém.
Một mối đe dọa khác là sự lười biếng, nguy cơ người kiểm tra quyết định không kiểm tra công việc của người khẳng định. (Hãy nhớ rằng, người chơi cờ có thể nói rằng họ đang kiểm tra nhưng thực tế không làm như vậy.) Hãy xem xét các động cơ khuyến khích người chơi cờ để xem đây có phải là một chiến lược hợp lý hay không.
Giả sử người khẳng định gian lận với xác suất X. Bây giờ, tiện ích của thanh tra như sau:
Nếu người đánh giá kiểm tra: RX-C
Nếu người kiểm tra không kiểm tra: -XL
Việc kiểm tra chỉ có giá trị nếu lợi ích của việc kiểm tra lớn hơn lợi ích của việc không kiểm tra, nghĩa là nếu X > C/(R+L). Đây là tin xấu: người khẳng định có thể gian lận ngẫu nhiên, với xác suất nhỏ hơn C/(R+L), người kiểm tra lý trí sẽ không bao giờ kiểm tra, vì vậy người khẳng định sẽ không bao giờ bị phát hiện gian lận.
Hãy cắm một số con số. Nếu chi phí kiểm tra mỗi giao dịch là 0,10 USD và người kiểm tra nhận được tiền thưởng là 75 USD nếu phát hiện gian lận, nhưng mất 25 USD nếu không phát hiện ra gian lận, thì người khẳng định có thể gian lận mà không bị trừng phạt Một nghìn lần. Nếu chúng ta muốn hệ thống này thực hiện hàng nghìn giao dịch thì chúng ta gặp vấn đề lớn. Rõ ràng chúng ta không thể làm gì trong mô hình này để giảm xác suất gian lận xuống 0. Chúng ta chỉ có thể hy vọng vào một hệ thống được thế chấp quá mức để mẫu số của C/(R+L) trở nên lớn hơn.
Đây là một kết quả mạnh mẽ đáng ngạc nhiên – theo một cách tồi tệ. Nó hoàn toàn không phụ thuộc vào động cơ của người khẳng định. Miễn là người khẳng định có được lợi thế khác 0 từ việc gian lận thành công, thì người đó có thể làm như vậy với một xác suất nào đó, dù biết rằng nỗ lực của người kiểm tra là không đáng. Kết quả này cũng không phụ thuộc vào việc chúng ta dành bao nhiêu thời gian cho thanh tra viên để hoàn thành công việc hoặc liệu chúng ta có trả tiền cho thanh tra viên (có mục đích) hay không. Có lẽ bây giờ bạn đang nghĩ, vấn đề là chỉ có một thanh tra. Việc thêm nhiều quân cờ có làm giảm khả năng gian lận không? Đáng ngạc nhiên là nó không.
Thêm người kiểm duyệt không giúp ngăn chặn gian lận
Một lần nữa, hãy xây dựng một mô hình đơn giản nhất. Hiện nay có hai thanh tra viên hoạt động độc lập. Mỗi người kiểm tra trả tiền C nếu kiểm tra và nếu ai đó kiểm tra và bắt được người khẳng định gian lận, phần thưởng R sẽ được trả cho người kiểm tra thành công hoặc nếu cả hai đều kiểm tra, phần thưởng sẽ được chia đều cho cả hai. (Nếu muốn, bạn có thể trao cho một trong số họ phần thưởng R đầy đủ ngẫu nhiên trong trường hợp tất cả họ đều check. Điều này không ảnh hưởng đến chiến lược hoặc kết quả của bất kỳ ai.) Như trước đây, mỗi người kiểm tra sẽ mất L nếu người khẳng định Gian lận mà không nhận được bắt gặp.
Vẫn xảy ra trường hợp nếu người khẳng định gian lận ít hơn C/(R+L) tại thời điểm đó, thì người kiểm tra sẽ không đáng để kiểm tra, vì lợi ích của việc kiểm tra nhỏ hơn lợi ích của việc không kiểm tra. Trên thực tế, vấn đề khuyến khích còn tệ hơn trước, vì chi phí kiểm tra cho mỗi người kiểm tra vẫn là C, nhưng phần thưởng mong đợi cho một người kiểm tra bắt gian lận thành công nhỏ hơn R, vì phần thưởng đôi khi cần được chia đôi - phần thưởng mong đợi sẽ ở trong R/2 và R. Nếu phần thưởng mong đợi là bR, trong đó b nằm trong khoảng từ 0,5 đến 1, thì người khẳng định có thể gian lận tới C/(bR+L) tại thời điểm đó - đây là hành vi gian lận khó bị phát hiện hơn so với khi chỉ có một người kiểm tra! (Phép toán hơi phức tạp vì giá trị của b phụ thuộc vào chiến lược của người kiểm tra và chiến lược của họ phụ thuộc vào b, nhưng cần phải rõ ràng rằng đôi khi họ sẽ cần chia phần thưởng. Ngoài ra, giá trị hiệu quả của L cũng bị giảm , vì một người không chơi Cờ đam có thể không bị mất L khi bị người cờ khác kiểm tra).
Một nơi mà việc bổ sung thêm cơ quan kiểm duyệt sẽ thực sự hữu ích là ngăn chặn hối lộ. Với hai quân cờ, người khẳng định phải trả một khoản hối lộ lớn hơn R cho mỗi người khẳng định, khiến khoản hối lộ đắt gấp đôi, cho phép đặt cược 50% thay vì đặt cược toàn bộ. Nhưng sự đánh đổi là số lượng gian lận tăng lên.
Tôi sẽ không đi sâu vào tất cả các phép toán ở đây, nhưng với những giả định hợp lý, việc tăng từ một quân cờ lên hai quân cờ có thể dẫn đến tỷ lệ gian lận không bị phát hiện tăng 50%.
Thêm người kiểm duyệt làm cho mọi thứ tồi tệ hơn!
Bạn có thể thêm nhiều người kiểm tra hơn và mọi thứ sẽ trở nên tồi tệ hơn. Khi số lượng người kiểm tra tăng lên, người kiểm tra cần lo lắng hơn về việc phần thưởng được chia theo nhiều cách, do đó phần thưởng mong đợi cho mỗi người kiểm tra thành công giảm dần, khiến xác suất người kiểm tra gian lận an toàn tăng dần. Từ góc độ này, trường hợp xấu nhất là mọi người trên thế giới đều có thể trở thành người kiểm duyệt. Điều này không hẳn là tệ, vì mọi thứ trở nên tồi tệ hơn khi có thêm nhiều cơ quan kiểm duyệt, nhưng chắc chắn nó sẽ không giúp ngăn chặn gian lận, ngay cả khi nó loại bỏ nguy cơ hối lộ một cách hiệu quả.
Bạn có chắc hệ thống của bạn tương thích với khuyến khích không?
Nếu bạn có một hệ thống phù hợp với loại mô hình này và bạn cho rằng nó có khả năng khuyến khích tương thích, bạn cần suy nghĩ cẩn thận về lý do. Đặc biệt, bạn cần giải thích lý do tại sao người kiểm tra lại thực hiện công việc kiểm tra, ngay cả khi họ cho rằng người kiểm tra khó có thể gian lận. Chỉ phạt nặng hành vi gian lận thôi là chưa đủ. Chỉ có phần thưởng cho việc bắt được kẻ gian lận là chưa đủ. Chỉ có nhiều người kiểm tra thôi là chưa đủ - trên thực tế, nó có thể khiến mọi việc trở nên tồi tệ hơn. Tại sao hệ thống của bạn miễn dịch?
Thử thách này áp dụng cho các hệ thống như Optimistic Rollup. Khi chúng ta nói về Trọng tài, nó cũng áp dụng cho chúng ta.
Cân nhắc những điều trên, các phương pháp kiểm tra khuyến khích truyền thống không đạt được kết quả mong muốn - có tỷ lệ gian lận cơ bản mà dưới mức đó người kiểm tra sẽ coi việc kiểm tra là không đáng giá. Tóm lại là:
Có hai người chơi, một người khẳng định, đưa ra khẳng định xem nó đúng hay sai, và một người kiểm tra, người có thể kiểm tra khẳng định đó với một chi phí tính toán nào đó. Nếu người kiểm tra kiểm tra, tiện ích của anh ta là RX-C, nếu anh ta không kiểm tra, tiện ích của anh ta là -XL, trong đó R là phần thưởng cho việc bắt gian lận, C là chi phí kiểm tra và L là tổn thất của người kiểm tra do không phát hiện gian lận , X là xác suất người khẳng định gian lận (do người khẳng định chọn). Một số đại số cho thấy rằng nếu
Để giải quyết vấn đề này và tạo ra tình huống mà người đánh giá luôn kiểm tra, chúng ta phải thay đổi động cơ của người đánh giá. Vấn đề cơ bản là trong mô hình ban đầu, các động cơ tích cực để người kiểm tra kiểm tra đều tỷ lệ thuận với Nếu chúng ta muốn khuyến khích kiểm tra hoạt động bất kể, chúng ta cần tạo ra khuyến khích kiểm tra hoặc khuyến khích không kiểm tra độc lập với hành động của người khẳng định.
TrueBit cố gắng thực hiện điều này bằng cách thêm các xác nhận quyền sở hữu sai có chủ ý vào tập hợp các xác nhận, về cơ bản thay thế X bằng X cộng với một hằng số. Có một số vấn đề với cách tiếp cận này. (Bài viết gốc của Arbitrum có một phần về các vấn đề động lực của TrueBit.)
Tập trung vào những thách thức
Chúng tôi sử dụng một cách tiếp cận khác mà chúng tôi gọi là tập trung vào thử thách. Ý tưởng là nếu người xác nhận đang tính toán một giá trị f(x), thì trước tiên nó sẽ đưa ra x và một thử thách mật mã. Để trả lời câu hỏi một cách chính xác, giám khảo cần biết f(x). Chỉ sau khi thử thách xảy ra, người xác nhận mới công bố f(x) - tại thời điểm này, người kiểm tra đã thực hiện công việc khó khăn là tính f(x), vì vậy nó không có động cơ để lười biếng. (Thông tin chi tiết về thỏa thuận sẽ được cập nhật sau.)
Để giảm số lượng giao dịch trực tuyến mà điều này yêu cầu, chúng tôi sẽ sắp xếp mọi thứ sao cho phản ứng chính xác trước thách thức của người kiểm tra thường là im lặng. Nhưng trong một số trường hợp hiếm hoi, người kiểm tra phải công bố một giao dịch rất nhỏ trên chuỗi. Nếu người kiểm tra đưa ra câu trả lời sai - im lặng khi đáng lẽ phải thả ra hoặc im lặng khi lẽ ra nên thả ra - thì người kiểm tra sẽ mất một khoản tiền gửi nhỏ.
Hãy điều chỉnh mô hình khuyến khích ban đầu để kết hợp các thách thức về sự chú ý. Chúng ta cần hai tham số mới (cả hai đều chúng ta có thể chọn): P, phần trăm thời gian đăng câu trả lời đúng của người kiểm tra và A, hình phạt nếu người kiểm tra đưa ra câu trả lời sai. Bây giờ, tiện ích của thanh tra là:
Nếu được chọn: RX-C
Nếu không kiểm tra: -LX-PA
Quan sát quan trọng là miễn là PA > C thì việc kiểm tra là chiến lược tối ưu, bất kể X (xác suất gian lận) là bao nhiêu.
Chi phí rất thấp
Để đánh giá chi phí, chúng ta hãy xem một ví dụ cụ thể. Giả sử cứ năm phút lại có một xác nhận và chi phí kiểm tra là 0,001 USD. Nếu chúng ta đặt xác suất P là 0,3%, người kiểm tra sẽ phải đặt cọc 3 USD. Giờ đây, chi phí cho mỗi xác nhận của người kiểm tra là 0,0003 USD phí gas (phí gas 0,10 USD để đăng phản hồi không im lặng, nhân với xác suất 0,3% mà nó phải đăng), cộng với khoảng 0,0003 USD để khóa khoản đặt cược 3 USD trong 5 phút. chi phí lãi vay là 0,0006 USD cho mỗi xác nhận.
Tiện ích mở rộng cho nhiều thanh tra viên
Thử thách tập trung có quy mô phù hợp với nhiều giám khảo. Giao thức đưa ra một thử thách ảnh hưởng đến mỗi trình kiểm tra một cách khác nhau, buộc mỗi trình kiểm tra phải tự tính toán f(x). Mỗi người kiểm tra sẽ có cùng mức chi phí (trong trường hợp của chúng tôi là 0,0006 USD cho mỗi xác nhận).
Trong một hệ thống mở, bất kỳ ai cũng có đủ điều kiện để kiểm tra các phép tính và bạn có thể cho phép bất kỳ ai đăng ký làm người kiểm tra và đặt khoản tiền gửi nhỏ cần thiết. Điều này sẽ khiến họ đủ điều kiện nhận được các thách thức về sự chú ý và có khả năng nhận được tiền bồi thường từ các nhà phát triển dapp. Bất kỳ ai cũng có thể phản đối những tuyên bố không chính xác của người khẳng định, nhưng chỉ những giám khảo đã đăng ký mới phải đối mặt với những thách thức về sự chú ý.
Chi tiết kỹ thuật của thỏa thuận
Bây giờ chúng ta đã hiểu việc tập trung vào các thách thức có thể mang lại lợi ích gì cho chúng ta, hãy cùng đi sâu vào chi tiết kỹ thuật về cách chúng hoạt động.
Mỗi trình kiểm tra có khóa riêng k và khóa chung gᵏ tương ứng, được xác định trong một nhóm thích hợp. Khóa công khai của mỗi người kiểm tra đều được mọi người biết. Chúng ta cũng sẽ dựa vào hàm băm H phù hợp.
Để đưa ra một thách thức đối với việc tính toán f(x), trong đó hàm f đã được biết trước, trình xác nhận tạo ra một giá trị ngẫu nhiên r và sau đó đưa ra (x, gʳ) như một thách thức.
Người kiểm tra sở hữu khóa riêng k sẽ phản hồi thử thách bằng cách chỉ xuất bản một giao dịch nhỏ nếu H(gʳᵏ, f(x)) < T, trong đó T là ngưỡng được chọn phù hợp. Lưu ý rằng chỉ người xác nhận (người biết r) và người kiểm tra cụ thể đó (người biết khóa riêng k của nó) mới có thể tính toán hàm băm, vì họ là những người duy nhất có thể tính gʳᵏ. Cũng lưu ý rằng việc tính toán hàm băm đòi hỏi phải biết f(x).
Sau khi người kiểm tra có thời gian để đăng câu trả lời của mình cho thử thách, người kiểm tra có thể đăng f(x) của mình và nếu bất kỳ người kiểm tra nào không đồng ý với nó, nó sẽ được thử thách như bình thường. Tại thời điểm này, người khẳng định có thể buộc tội bất kỳ người kiểm tra nào về những phản hồi không chính xác; người khẳng định phải đưa ra r để chứng minh cho lời buộc tội của mình. Người khai thác hoặc hợp đồng có thể kiểm tra xem lời buộc tội có đúng hay không và trừng phạt người vi phạm; nhưng nếu khẳng định của người khẳng định về f(x) cuối cùng không được chấp nhận là đúng thì lời buộc tội đó sẽ bị bỏ qua. Nếu bất kỳ người kiểm tra nào bị phạt, người xác nhận sẽ nhận được một nửa số tiền bị tịch thu và nửa còn lại sẽ bị tiêu hủy.
Cách tiếp cận này mang lại cho người kiểm tra những khuyến khích phù hợp. Để biết cách người kiểm tra phản ứng với một thử thách đòi hỏi phải biết khóa riêng của người kiểm tra đó và f(x), vì vậy mỗi người kiểm tra sẽ muốn tính f(x). Trừ khi trình kiểm tra tự tính toán f(x), nó không thể thực thi giao thức một cách an toàn. Phản hồi của những người kiểm tra khác không hữu ích trong việc xác định f(x) vì chúng dựa vào khóa riêng của những người kiểm tra đó. Nếu người kiểm tra dựa vào người khác nói cho nó biết f(x), thì nó không có cách nào để xác minh giá trị được xác nhận đó (ngoài việc tính chính f(x)) và người kiểm tra có nguy cơ bị phạt nếu sai. Thậm chí còn có động cơ để một bên cố gắng đánh lừa người kiểm tra về f(x) - đó là người khẳng định, người thu lợi từ lỗi của người kiểm tra và có thể sử dụng lợi nhuận này để hối lộ "bạn bè" của người kiểm tra để cung cấp thông tin sai cho người kiểm tra .
Tối ưu hóa và kết luận
Có một số thủ thuật để làm cho giao thức này hiệu quả hơn. Ví dụ: chúng tôi có thể gộp một xác nhận với thử thách tiếp theo vào một giao dịch trực tuyến để thử thách không làm tăng số lượng giao dịch. Nếu P nhỏ (ví dụ: 0,3% trong ví dụ của chúng tôi) và số lượng người kiểm tra không lớn lắm thì người kiểm tra hiếm khi cần ghi giao dịch trên chuỗi, do đó tác động tổng thể của giao thức đến số lượng giao dịch trên chuỗi sẽ hãy nhỏ nhất.
Với việc triển khai thông minh, chi phí của giao thức này sẽ rất thấp so với chi phí ban đầu của việc đưa ra các xác nhận trên chuỗi. Trong trường hợp của chúng tôi, việc thêm các thách thức chú ý vào giao thức thách thức khẳng định hiện có sẽ làm tăng tổng chi phí ít hơn 1%.
Và lợi ích đạt được là đáng kể – chúng tôi nhận được một giao thức kiểm tra tương thích với khuyến khích, không gặp phải vấn đề nan giải của người xác nhận. Miễn là có ít nhất một người kiểm tra là hợp lý thì các tuyên bố của người khẳng định sẽ luôn được kiểm tra.
Để biết thêm thông tin về dự án, vui lòng tham khảo: Chuỗi công khai trò chơi Xai: cơ sở dữ liệu Binance Square