Cảm ơn Michael và Lin vì những phản hồi.
Tóm lại là...
Các giao thức tiền cấu hình đáng tin cậy yêu cầu người đề xuất phải xác minh rằng các cam kết của họ đã được thực hiện trước khi ký một khối. Một cách tiếp cận đơn giản, kiểm tra toàn bộ nội dung khối, sẽ làm lộ khối của người xây dựng, điều này là không thể chấp nhận được. Các bộ chuyển tiếp có thể lấp đầy khoảng trống này nhưng không bắt buộc sau ePBS. Giải pháp không cần tin tưởng là người xây dựng gửi bằng chứng về việc đáp ứng các ràng buộc cùng với giá thầu của họ. Nhược điểm là việc tạo bằng chứng làm tăng độ trễ cho đường dẫn quan trọng, đặc biệt nếu các ràng buộc phát triển vượt ra ngoài việc bao gồm giao dịch đơn giản.
EIP-7928 BAL cung cấp một giải pháp thay thế có cấu trúc. BAL là bản ghi đầy đủ của mọi thao tác ghi trạng thái trong một khối, được tạo ra như một sản phẩm phụ của quá trình thực thi và được ghi lại trong tiêu đề khối. Vì mỗi mục nhập BAL đều có cùng cấu trúc, nên bất kỳ loại cấu hình trước nào cũng có thể được quy về một truy vấn đúng/sai trên cùng một đối tượng. Một ngôn ngữ xác minh duy nhất có thể bao gồm bất kỳ loại cấu hình trước nào (bao gồm, thực thi, sắp xếp, loại trừ, v.v.) và một hàm xác minh duy nhất có thể xử lý tất cả mà không cần phải triển khai lại. Các loại cấu hình trước mới trở thành các công thức mới có thể được xác minh bằng cùng một cơ sở hạ tầng. Điều này cải thiện đáng kể các đảm bảo có thể đạt được thông qua bằng chứng Merkle, đồng thời giảm độ trễ và độ phức tạp.
Lý lịch
Các cam kết trước (preconf) cho phép người đề xuất cam kết, trước khi khối được tạo, rằng một số thuộc tính nhất định sẽ được giữ nguyên trong khối tiếp theo của họ. Người dùng có thể nhận được một cam kết trước đảm bảo giao dịch của họ sẽ được đưa vào, rằng một giá trị được ghi vào vị trí lưu trữ cụ thể hoặc rằng một khoản thanh toán vượt quá một ngưỡng nhất định sẽ được đưa vào khối.
Những cam kết mà người đề xuất đưa ra sẽ ràng buộc cách thức xây dựng khối. Hiện nay, nếu không có ràng buộc, người xây dựng có thể tự do trình bày bất kỳ khối nào cho người đề xuất. Ví dụ, với các cấu hình trước về việc bao gồm, người xây dựng bị ràng buộc phải trình bày các khối bao gồm các giao dịch được chỉ định.
Trước khi cam kết với một khối, người đề xuất cần một phương tiện để xác minh rằng khối đó đáp ứng tất cả các ràng buộc nhằm đảm bảo rằng cam kết của họ sẽ được thực hiện. Lưu ý sự khác biệt ở đây là cam kết hướng đến người dùng, còn ràng buộc hướng đến người xây dựng.
Vấn đề xác minh
Cách tiếp cận hiển nhiên là người đề xuất kiểm tra trực tiếp toàn bộ nội dung khối. Nếu khối đáp ứng các ràng buộc, người đề xuất sẽ ký. Nhưng điều này không khả thi vì nó sẽ cho phép người đề xuất đánh cắp khối mà không cần trả tiền cho người xây dựng.
Các máy chuyển tiếp hiện đã giải quyết vấn đề trao đổi công bằng này. Với cơ chế chuyển tiếp bi quan, máy chuyển tiếp thực thi toàn bộ khối lệnh trước khi chia sẻ tiêu đề với bên đề xuất để ký, và có thể mở rộng điều này để xác minh các ràng buộc preconf như một dịch vụ đáng tin cậy. Một phương án khác là chuyển tiếp lạc quan, trong đó máy chuyển tiếp chuyển tiếp chuyển tiếp tiêu đề mà không thực thi toàn bộ khối lệnh và thay vào đó dựa vào việc quy kết lỗi hồi tố: nếu khối lệnh của người xây dựng sau đó được phát hiện là không hợp lệ hoặc vi phạm ràng buộc, họ sẽ bị phạt. Cả hai chế độ này đều đang được sử dụng trong thực tế. Tuy nhiên, không chế độ nào tồn tại được sau khi ePBS được triển khai, vì ePBS loại bỏ hoàn toàn máy chuyển tiếp khỏi đường dẫn quan trọng.
Một giải pháp không cần tin tưởng là người xây dựng tạo ra bằng chứng về việc thỏa mãn ràng buộc cùng với giá thầu của họ. Hình thức đơn giản nhất là bằng chứng bao hàm Merkle đối với các gốc cây trie được cam kết trong tiêu đề khối. Người xây dựng có thể chứng minh một giao dịch cụ thể đã được bao gồm, hoặc một vị trí lưu trữ cụ thể là một giá trị được thiết lập ở cuối khối , mà không cần tiết lộ toàn bộ nội dung khối.
Một vấn đề là độ trễ. Việc tạo bằng chứng diễn ra sau khi khối được xây dựng hoàn chỉnh. Khi số lượng ràng buộc trước khi xác nhận tăng lên, việc tạo bằng chứng trở thành một bước không hề đơn giản trên đường dẫn quan trọng giữa việc xây dựng khối và việc gửi giá thầu. Mỗi mili giây đều làm mất đi thời gian xây dựng quý giá, ảnh hưởng đến doanh thu của người đề xuất.
Vấn đề khác là khả năng diễn đạt. Bằng chứng Merkle là bằng chứng cấp khối: chúng có thể chứng minh một giao dịch đã được bao gồm hoặc một vị trí trạng thái giữ một giá trị cụ thể, nhưng chúng không thể chứng minh sự khác biệt trạng thái ở cấp giao dịch. Không có bằng chứng Merkle nào chứng minh rằng một giao dịch cụ thể đã gây ra một thay đổi trạng thái cụ thể. Việc xác minh các cấu hình trước có trạng thái yêu cầu phải thực thi lại toàn bộ hoặc chứng minh ZK, điều này không khả thi vì lý do bảo mật hoặc độ trễ.
Danh sách chặn truy cập cung cấp những gì?
EIP-7928 định nghĩa Danh sách truy cập cấp khối (BAL) là bản ghi đầy đủ về tất cả các tài khoản và vị trí lưu trữ được truy cập trong quá trình thực thi khối. Mỗi BAL được liên kết với một giá thầu/khối cụ thể thông qua một block_access_list_hash , và bằng cách phát lại BAL, bất kỳ ai cũng có thể tính toán lại trạng thái cuối cùng của khối mà không cần thực hiện các giao dịch thực tế.
Trong bối cảnh các cuộc họp tiền hội nghị, điều này hữu ích vì hai lý do chính:
1. BAL là sản phẩm trực tiếp của quá trình thực thi. Không có bước tạo bằng chứng riêng biệt. Người xây dựng đã có nó khi khối được tạo. BAL ghi lại mọi thao tác ghi trạng thái xảy ra trong quá trình tạo khối: giá trị khe lưu trữ, thay đổi số dư, tăng nonce và cập nhật mã, mỗi thao tác được gắn thẻ bằng block_access_index để nắm bắt thứ tự ghi toàn cục. Điều này đủ để người đề xuất xác minh trực tiếp bất kỳ thuộc tính nào về kết quả trạng thái: giá trị được ghi vào khe là gì, số dư tài khoản có vượt qua ngưỡng hay không, nonce có tăng hay không, hai thao tác ghi có xảy ra theo một thứ tự cụ thể hay không, hoặc hợp đồng có bị tác động hay không. Không cần kiểm tra giao dịch cho bất kỳ thao tác kiểm tra nào trong số này.
2. BAL có thể được xác minh mà không làm rò rỉ nội dung của khối. Việc tái tạo một khối yêu cầu các giao dịch đã ký thực tế và các dữ liệu đầu vào của chúng, điều mà BAL bỏ qua. Người đề xuất chỉ kiểm tra BAL sẽ không biết được gì cho phép họ tái tạo và gửi lại khối mà không cần trả tiền cho người xây dựng. Tuy nhiên, nếu mọi giao dịch đều đến từ mempool công khai, về nguyên tắc, người đề xuất quyết tâm có thể tái tạo nó chỉ từ thông tin công khai (nhưng trong trường hợp đó, họ có thể tự xây dựng khối tương tự mà không cần BAL của người xây dựng). Các khối có luồng lệnh riêng tư không thể được tái tạo.
Từ cam kết giao dịch đến xác nhận kết quả trước khi thực hiện
Các phương pháp tiền cấu hình hiện tại đưa ra những lời hứa về các giao dịch đã ký cụ thể. Tiền cấu hình dựa trên kết quả chuyển hướng khỏi các giao dịch và chỉ tập trung vào những lời hứa về trạng thái.
Với các ý định hiện tại, bạn quy định một kết quả nhất định, chẳng hạn như “đổi X lấy ít nhất Y ”, các bộ giải sẽ cạnh tranh để tìm ra các giải pháp tùy chỉnh, sau đó hợp đồng thông minh sẽ xác minh cuối cùng xem ý định đó đã được đáp ứng hay chưa. Các cấu hình trước kết quả áp dụng cùng một mô hình ở lớp đề xuất. Khi người đề xuất cam kết “lần ghi đầu tiên vào vị trí S sẽ có giá trị V ”, họ đang cam kết với một kết quả trạng thái, chứ không phải một đường dẫn thực thi. Người xây dựng có thể đáp ứng ràng buộc này thông qua bất kỳ chuỗi giao dịch hợp lệ nào vì ràng buộc không nói gì về giao dịch nào tạo ra thao tác ghi, ai đã gửi nó, lượng gas tiêu thụ là bao nhiêu, v.v.
Nói một cách đơn giản, người đề xuất thể hiện các kết quả mong muốn của khối, những người xây dựng cạnh tranh để tìm ra bất kỳ đường dẫn thực thi hợp lệ nào đạt được các kết quả đó, và người đề xuất xác minh các kết quả đã đạt được (thông qua BAL) trước khi cam kết vào khối (và không làm rò rỉ nội dung của khối).
Ngôn ngữ ràng buộc thống nhất
BAL là một cấu trúc duy nhất mà dựa vào đó bất kỳ loại xác thực trước nào cũng có thể được kiểm chứng. Đây là một sự thay đổi đáng kể so với cách thức hoạt động của các xác thực trước hiện nay, trong đó mỗi loại là một vấn đề thiết kế riêng: xác thực trước bao gồm yêu cầu một định dạng bằng chứng, ràng buộc thứ tự yêu cầu một định dạng khác, xác thực trước thực thi lại yêu cầu một định dạng khác nữa. Mỗi loại mới đòi hỏi logic xác minh mới cho người đề xuất và cơ sở hạ tầng xử phạt trên chuỗi mới. Việc thêm một loại xác thực trước mới đồng nghĩa với việc nâng cấp phối hợp trên mọi lớp của kiến trúc.
Vì mỗi mục BAL đều có chung bốn trường (địa chỉ, loại trường, giá trị được ghi và chỉ số thứ tự), việc xác minh bất kỳ kết quả nào trước khi cấu hình đều quy về cùng loại câu hỏi đúng/sai: liệu có tồn tại thao tác ghi nào với các thuộc tính này không? Địa chỉ này có bị thiếu không? Thao tác ghi A có xảy ra trước thao tác ghi B không?
Logic bậc nhất (FOL) là một ngôn ngữ hình thức để tạo ra chính xác những loại phát biểu đúng/sai này về một tập hợp các đối tượng cố định. Nó được hiểu rõ và được biết là hoàn chỉnh trên các cấu trúc hữu hạn: bất kỳ thuộc tính Boolean nào bạn có thể diễn đạt bằng tiếng Anh thông thường về một BAL có lược đồ cố định đều có thể được biểu diễn dưới dạng công thức FOL.
Hậu quả thực tiễn là chỉ cần một bộ xác minh duy nhất. Bộ xác minh này nhận công thức FOL và BAL làm đầu vào và trả về giá trị đúng hoặc sai. Chức năng xác minh được xây dựng một lần (trong phần phụ trợ của bên đề xuất cho quy trình đấu thầu thông thường, và trong hợp đồng phân bổ cho các tranh chấp) và không bao giờ cần thay đổi. Một loại preconf mới có nghĩa là viết một công thức FOL mới, chứ không phải triển khai cơ sở hạ tầng mới.
Ngôn ngữ này có hai loại phần tử cơ bản. Phép so sánh là các phần tử lá: sự bằng nhau, không bằng nhau của trường và các phép kiểm tra thứ tự ( == , >= , < , v.v.) được áp dụng cho các giá trị trong các mục khớp. Các phép toán logic là cấu trúc: “tồn tại một mục thỏa mãn…”, “cả hai điều kiện đều đúng”, và “điều kiện này không đúng”. Đây là nguyên tắc tương tự như việc xây dựng bất kỳ mạch logic nào từ một loại cổng duy nhất, chỉ với các phần tử cơ bản tối thiểu, bạn có thể đạt được khả năng biểu đạt không giới hạn.
Các Dapp được kỳ vọng sẽ tính toán các công thức thay mặt người dùng. Điều này bao gồm việc xác định các vị trí lưu trữ nào bị ảnh hưởng bởi giao dịch của người dùng và có liên quan đến việc kiểm tra trong BAL (Số dư). Đối với các ràng buộc số học (“số dư tăng thêm Y ”, “giá trong phạm vi 5% ”, “số nonce tăng dần”), dapp cung cấp trực tiếp các gợi ý này cho công thức, có nghĩa là bản thân ngôn ngữ không cần hỗ trợ số học. Cụ thể, nếu nonce của Alice là 5 và số dư USDC của cô ấy là 500 , và cô ấy muốn nhận ít nhất 2000 USDC, dapp sẽ đọc trạng thái trước đó, tính toán 6 và 2500 , và xây dựng một công thức chỉ đơn giản kiểm tra nonce == 6 và balance >= 2500 .
Kết quả: Các mô hình trước hội nghị và UX L1
Mỗi mẫu sau đây là một công thức trên BAL. Cùng một trình xác thực xử lý tất cả chúng. Lưu ý rằng chúng chỉ mang tính chất minh họa và có thể không đầy đủ. Trong các công thức bên dưới, (A, Nonce) và (A, Balance) đề cập đến trường nonce và số dư ETH của tài khoản A ; (C, S) đề cập đến khe lưu trữ S trong hợp đồng C ; và V là giá trị dự kiến sẽ có. Chúng tương ứng trực tiếp với các loại trường trong một mục nhập BAL.
Đảm bảo việc ghi nhận. Alice muốn giao dịch chuyển ETH của cô ấy cho Bob được ghi nhận trong khối tiếp theo. Việc tăng nonce của Alice xác nhận giao dịch của cô ấy đã được thực hiện và việc tăng số dư của Bob xác nhận khoản thanh toán đã được nhận. Hai thao tác ghi phải có cùng block_access_index để xác nhận chúng đến từ cùng một giao dịch. Ứng dụng phi tập trung (dapp) tính toán các giá trị trạng thái sau tuyệt đối từ gốc trạng thái cha trước khi xây dựng công thức.
there exists a write to ( Alice, Nonce ) with value == n+ 1 [call this e1] AND there exists a write to ( Bob, Balance ) with value > = bob_pre_balance + amount AND index == e1.index Đầu khối. Giao dịch của người dùng phải là giao dịch người dùng đầu tiên trong khối. block_access_index được gán cho mỗi giao dịch, trong đó chỉ số 0 được dành riêng cho việc ghi hợp đồng hệ thống trước khi thực thi (ví dụ: cập nhật gốc tín hiệu EIP-4788), và các giao dịch của người dùng được gán chỉ số bắt đầu từ 1 Đây là sự đảm bảo thứ tự mạnh nhất hiện có và nên được định giá tương ứng.
there exists a write to (Alice, Nonce) with value == n+ 1 AND index == 1 AND there exists a write to (C, S) with value == V AND index == 1 Quyền truy cập hợp đồng đầu tiên. Người dùng muốn là người đầu tiên tương tác với một hợp đồng cụ thể, nhưng không muốn trả phí cho quyền truy cập ở đầu khối. Ví dụ kinh điển là việc tạo NFT: người đầu tiên gọi hàm tạo, không quan tâm đến mọi thứ khác. Phạm vi kiểm tra chỉ giới hạn ở các mục nhập của hợp đồng C , cho phép người xây dựng hoàn toàn tự do sắp xếp thứ tự mọi thứ khác.
there exists a write to (C, S) with value == VAND its index is less than or equal to every other write to C Thanh toán ý định cùng một vị trí. Người dùng ký một ý định, "đổi X ETH của tôi lấy ít nhất Y USDC", mà không chỉ định cách thức thực hiện. Trình tạo bao gồm cả giao dịch ý định của người dùng và giao dịch thực hiện của bộ giải. Ràng buộc thứ tự trong công thức đảm bảo ý định được thực hiện trước khi bộ giải thanh toán. Điều quan trọng là, sự cạnh tranh lành mạnh giữa các trình tạo rất quan trọng để cải thiện kết quả cho người dùng.
there exists a write to ( A, Nonce ) with value == n+ 1 [call this e1] AND there exists a write to ( A, ETH_Balance ) with value < = eth_pre_balance - X AND index == e1. indexAND there exists a write to ( A, USDC_Balance ) with value > = Y [call this e2]AND e1.index < e2.indexXác nhận trước kết quả thực thi. Trong lịch sử, việc đảm bảo trạng thái sau thực thi cụ thể yêu cầu bằng chứng ZK qua quá trình thực thi EVM. Với BAL, việc tăng nonce xác nhận giao dịch của người dùng đã chạy; việc kiểm tra khe lưu trữ xác nhận sự thay đổi trạng thái dự kiến. Cả hai thao tác ghi phải dùng chung một chỉ mục để xác nhận chúng đến từ cùng một giao dịch. Không cần thực thi lại.
there exists a write to ( A, Nonce ) with value == n+ 1 [call this e1] AND there exists a write to ( C, S ) with value == V AND index == e1.index Các mẫu trên được kết hợp tự do. Một đảm bảo ở đầu khối có thể được thêm vào một thỏa thuận ý định cùng vị trí bằng cách thêm index == 1 vào kiểm tra nonce. Một kết quả thực thi có thể được kết hợp với một ràng buộc thứ tự. Bất kỳ sự kết hợp nào của những điều trên đều là một công thức hợp lệ và được xác minh bằng cùng một hàm xác minh.
Kết quả trước hội nghị với ePBS
Vì các yêu cầu xác nhận trước đó được giới hạn trong kết quả chứ không phải các giao dịch cụ thể, việc đáp ứng chúng trở thành một thị trường. Nhiều người tìm kiếm có thể cạnh tranh độc lập để đáp ứng bất kỳ yêu cầu xác nhận trước đó nào. Người xây dựng sẽ chọn gói tốt nhất. Không cần thiết phải để một bên xem chiến lược thực thi của bên khác. Trình tự bên dưới cho thấy điều này phù hợp với quy trình đấu thầu sau ePBS như thế nào.
Lưu ý, cam kết ràng buộc đã ký của người xây dựng không đóng vai trò gì trong luồng trên chuỗi. Mục đích của nó nằm ngoài giao thức: người xây dựng ký các ràng buộc và sau đó gửi BAL vi phạm chúng đã tạo ra bằng chứng mật mã về lỗi của chính họ, mà một hệ thống xử phạt hoặc đánh giá uy tín bên ngoài có thể dựa vào đó để xử lý.
Bước xác minh ràng buộc được thực thi trong sidecar của bên đề xuất, một triển khai ngoài chuỗi của cùng một logic xác minh được triển khai trong hợp đồng phạt. Về bản chất, hai bước này tương đương nhau, vì vậy bên đề xuất xác nhận cùng một kiểm tra mà hợp đồng phạt sẽ thực hiện sau này trong trường hợp tranh chấp.
Cũng cần lưu ý, trong đặc tả ePBS, giá thầu của người xây dựng chứa cam kết block_hash , chứ không phải chính tiêu đề. Do đó, người đề xuất cần thiết lập chuỗi tin cậy từ BAL → block_access_list_hash → tiêu đề → block_hash → giá thầu.
Hạn chế
BAL không chứng minh rằng các giao dịch cơ bản có chữ ký hợp lệ. Người xây dựng có thể tạo ra một BAL đáp ứng tất cả các kiểm tra tiền xác thực kết quả nhưng lại tương ứng với các giao dịch không hợp lệ hoặc bịa đặt. Khi dữ liệu được tiết lộ, nó sẽ không vượt qua quá trình xác thực và người đề xuất sẽ mất suất của mình. May mắn thay, người đề xuất vẫn được thanh toán số tiền đấu thầu vô điều kiện sau khi ePBS kết thúc.
Nếu không có cơ chế xử phạt vi phạm giao thức để ngăn chặn hành vi này của người xây dựng, các thỏa thuận trước khi xác nhận kết quả có thể càng khuyến khích người xây dựng sử dụng quyền miễn phí của họ nếu việc vi phạm các cam kết trước khi xác nhận có thể mang lại lợi nhuận. Việc người xây dựng hoặc thậm chí nhiều bên cùng cam kết tuân thủ các ràng buộc là một bước tiến hướng tới cơ chế như vậy.
BAL như bằng chứng tranh chấp
Nếu tranh chấp trước khi xác nhận kết quả được đưa ra xét xử trên chuỗi, mỗi ràng buộc đều có thể bị tranh chấp độc lập. Bên tranh chấp cung cấp ràng buộc bị vi phạm, chữ ký của người đề xuất trên đó, cam kết đã ký của người xây dựng, BAL và tiêu đề khối. Hợp đồng xử phạt sẽ xác thực BAL so với block_access_list_hash và chạy cùng một trình xác minh mà sidecar của người đề xuất đã chạy trong quá trình xác minh thông thường. Nếu nó trả về false, thì vi phạm được chứng minh.
Cấu trúc công thức FOL rất phù hợp với việc chứng minh ZK. Việc chứng minh các truy vấn trên BAL có lược đồ cố định rẻ hơn nhiều so với việc thực thi EVM tùy ý, vì vậy việc chứng minh ZK dựa trên gốc BAL đã được cam kết là một tối ưu hóa khả thi trong tương lai.
Một con đường hướng tới việc tôn vinh
Thiết kế được mô tả trong bài báo này hoàn toàn nằm ngoài giao thức. Các cam kết của bên đề xuất và bên xây dựng được thực thi thông qua các ưu đãi kinh tế và việc xử phạt ngoài giao thức. Một khối vi phạm các điều kiện tiên quyết về kết quả vẫn là một khối hợp lệ từ góc nhìn của mạng lưới.
Có một hướng đi khả thi để hiện thực hóa điều này trong giao thức. PEPC đã xác định nhu cầu về các cam kết của người đề xuất được thực thi bởi giao thức nhưng vẫn để ngỏ vấn đề về cách biểu diễn cam kết, liệu có nên sử dụng thực thi EVM, SNARK hay một cấu trúc nào khác, và lưu ý một vấn đề về tính khả dụng của dữ liệu: làm thế nào các bên thứ ba có thể cung cấp bằng chứng cam kết theo cách mà người chứng thực có thể xác minh? BAL có khả năng giải quyết cả hai vấn đề vì nó đã là một đối tượng hạng nhất được cam kết trong tiêu đề khối, do đó không cần cơ chế cung cấp bằng chứng riêng biệt. Ngôn ngữ ràng buộc FOL là tối thiểu và được định nghĩa rõ ràng, và trình xác minh là một hàm duy nhất có thể triển khai ở lớp đồng thuận. Thay vì để người chứng thực thực thi lại mã cam kết, giao thức có thể xác minh trực tiếp các công thức FOL dựa trên BAL đã được xác thực.
Để điều này hoạt động đúng theo quy trình, cần phải có thêm một số yếu tố khác nữa:
Phát sóng cam kết ràng buộc. Các ràng buộc của người đề xuất cần được công bố trước quá trình đấu thầu, theo cách không thể thay đổi và có thể quy kết được. Tương tự như PTC nhưng dành cho các ràng buộc.
BAL và phần tiêu đề được gửi kèm theo hồ sơ dự thầu. Để nhà thầu xác minh các ràng buộc trước khi ký kết, nhà thầu xây dựng phải đính kèm BAL và phần tiêu đề cùng với hồ sơ dự thầu, điều này hiện không nằm trong quy định của ePBS.
Hình phạt dành cho nhà thầu xây dựng vì BAL không hợp lệ. Nếu BAL được nộp kèm theo giá thầu không khớp với lô đất được tiết lộ cuối cùng, hoặc nếu lô đất được tiết lộ không được xác thực, nhà thầu xây dựng sẽ bị phạt. Sau khi áp dụng ePBS, các nhà thầu xây dựng đã được yêu cầu ký quỹ bảo đảm nên phần lớn công việc khó khăn đã được hoàn thành.
Bản tóm tắt
Theo ePBS, các relay không bắt buộc nên việc giới thiệu lại chúng như một trình xác minh preconf đáng tin cậy là không lý tưởng. Bằng chứng Merkle cung cấp một giải pháp thay thế không cần tin tưởng nhưng lại làm tăng độ trễ cho đường dẫn quan trọng và không thể thể hiện các ràng buộc trạng thái hoặc loại trừ. BAL giải quyết cả hai vấn đề: chúng được tạo ra như một sản phẩm phụ của việc thực thi khối mà không làm tăng thêm độ trễ, và bằng cách chuyển từ cam kết cấp giao dịch sang cam kết cấp ý định, bất kỳ loại preconf nào cũng được rút gọn thành một công thức trên cùng cấu trúc BAL. Khả năng thể hiện này không yêu cầu bằng chứng ZK trên đường dẫn quan trọng, và việc thêm các loại preconf mới không yêu cầu thay đổi nào đối với cơ sở hạ tầng xác minh hoặc cơ chế phạt.
