Đặc biệt cảm ơn Jon Charbonneau và Conor McMenamin đã xem xét bài viết này.

Tại thời điểm này, tất cả chúng ta nên biết rằng các quy tắc xác nhận có tính bảo mật chứ không phải bản thân các bản tổng hợp. Khi chúng tôi nói rằng các bản tổng hợp kế thừa “bảo mật Ethereum” hoặc chúng được “giảm thiểu độ tin cậy”, điều chúng tôi thực sự muốn nói là trên các bản tổng hợp, có thể sử dụng các quy tắc xác nhận có mức độ bảo mật tương tự như các quy tắc xác nhận Ethereum. Tuy nhiên, những người khám phá khối chủ yếu quan tâm đến việc hiển thị huy hiệu màu xanh lá cây mà không đi sâu vào chi tiết về quy tắc xác nhận mà họ đang đề cập đến hoặc thuộc tính bảo mật nào họ cung cấp.

Tại L2BEAT, chúng tôi muốn giải quyết vấn đề này và giúp mọi người có thể truy cập được. Đặc biệt, chúng tôi muốn tập trung vào tính hữu hạn, quy tắc xác nhận mạnh nhất chống lại các cuộc tấn công chi tiêu gấp đôi.

Quy tắc xác nhận: tính nhất quán và tính khả dụng

Quy tắc xác nhận là các thuật toán, theo các giả định cụ thể, cho biết khi nào một khối được xác nhận và không có khả năng được sắp xếp lại. Khi một khối được xác nhận, các hành động liên quan đến giao dịch của nó có thể được thực hiện. Ví dụ: điều này có thể liên quan đến việc giao cà phê cho khách hàng hoặc giao ô tô cho người mua.

Các quy tắc xác nhận khác nhau cung cấp cho người dùng những đảm bảo bảo mật khác nhau. Tính bảo mật của quy tắc xác nhận bao gồm tính nhất quán và tính khả dụng và phụ thuộc rất nhiều vào các thuật toán đồng thuận cơ bản:

• Tính nhất quán (an toàn): chế độ xem của bất kỳ hai nút nào đều nhất quán trong các phân vùng mạng.
• Tính khả dụng (sự tồn tại): các giao dịch tiếp tục được đưa vào sổ cái trong một thời gian nhất định ngay cả sau khi một phần đáng kể các nút ngừng tham gia vào giao thức.

Định lý CAP cho chúng ta biết rằng không thể thiết kế một thuật toán đồng thuận vừa nhất quán trong các phân vùng mạng vừa khả dụng dưới sự tham gia động: nếu phân vùng mạng nghiêm trọng xảy ra, các nút có thể quyết định tiếp tục tạo khối và mất tính nhất quán hoặc dừng và mất tính sẵn có. Không có cách nào để các nút phân biệt giữa các nút khác chỉ đơn giản là ngoại tuyến (tham gia động) hoặc đang hoạt động nhưng không thể truy cập được (phân vùng mạng) và do đó không thể hành động khác đi.

Eve không thể biết liệu Bob chỉ đang ngoại tuyến hay đang ở trên một phân vùng mạng khác.

Các chuỗi khối như Bitcoin, sử dụng cơ chế đồng thuận giống Nakamoto, có tính sống động cao, có nghĩa là trong quá trình phân chia mạng, cả hai bên sẽ tiếp tục tạo ra các khối và cuối cùng sẽ tổ chức lại nếu phân vùng được giải quyết, trong khi các chuỗi khối khác như chuỗi Cosmos, sử dụng giống PBFT sự đồng thuận, tạm dừng theo các phân vùng mạng để duy trì tính nhất quán.

Quy tắc xác nhận trên Ethereum

Ethereum ưu tiên tính khả dụng trong các phân vùng mạng bằng thuật toán LMD GHOST . Cách tiếp cận này có nghĩa là các nút trung thực có thể có các chế độ xem khác nhau ở đầu chuỗi và có thể xác nhận các khối khác nhau có cùng độ cao, có khả năng dẫn đến việc tổ chức lại.

Trong điều kiện mạng thuận lợi, Ethereum cũng nhằm mục đích cung cấp sự đảm bảo tính nhất quán thông qua tính hữu hạn, sử dụng giao thức Casper FFG . Tính hữu hạn là quy tắc xác nhận mạnh nhất có thể, với các nút có quy tắc được mã hóa cứng để không bao giờ tổ chức lại các khối đã hoàn thiện.

Sổ cái cuối cùng (màu xanh lá cây) luôn là tiền tố của sổ cái trực tiếp (màu xanh lam).

Các đảm bảo về tính hữu hạn sẽ bị xâm phạm nếu hai khối xung đột được hoàn thiện, một sự kiện có thể xảy ra nếu hơn 1/3 số người xác thực có hành động độc hại. Tuy nhiên, trên Ethereum, những hành động như vậy đi kèm với hình phạt đáng kể là mất cổ phần.

Người dùng có thể chọn sử dụng Casper FFG làm quy tắc xác nhận an toàn nhất hay trực tiếp hơn bằng cách dựa vào LMD GHOST. Quy tắc xác nhận cho LMD GHOST, tương tự như quy tắc xác nhận k trong Bitcoin, có thể phức tạp hơn việc chỉ xem liệu giao dịch có được đưa vào sổ cái hay không, như được chỉ định trong quy tắc xác nhận Khối an toàn.

Quy tắc xác nhận về tổng hợp

Về nguyên tắc, các bản tổng hợp có thể sử dụng các quy tắc xác nhận tương tự có sẵn trên Ethereum. Nếu bạn gửi một giao dịch trong một bản tổng hợp và sau đó thấy giao dịch tương tự được đăng trên L1 trong một khối cuối cùng, bạn cũng có thể muốn coi giao dịch L2 là giao dịch cuối cùng. Hóa ra câu chuyện phức tạp hơn thế này nhiều.

Tổng hợp dữ liệu giao dịch

Trên Ethereum, các khối bao gồm cả danh sách giao dịch và trạng thái gốc được đề xuất trong tiêu đề khối. Nếu việc thực hiện các giao dịch không dẫn đến trạng thái mà gốc đại diện thì toàn bộ khối sẽ bị loại bỏ, bao gồm cả các giao dịch mà sau này có thể được thêm vào các khối khác theo thứ tự khác.

Khi tổng hợp, do hành động xuất bản dữ liệu và gốc được tách riêng nên các giao dịch không cần phải bị loại bỏ tùy thuộc vào tính hợp lệ của gốc trạng thái tương ứng. Với sự tách biệt này, việc kiểm tra xem các giao dịch có được hoàn tất hay không mà không cần chờ quyết toán gốc trạng thái là đủ, bỏ qua các độ trễ bổ sung chẳng hạn như giai đoạn thử thách 7 ngày trong các bản tổng hợp lạc quan.

Tổng hợp khác biệt trạng thái

Sự khác biệt trạng thái là kết quả đầu ra của hàm chuyển đổi trạng thái và để xác thực rằng chúng thực sự hợp lệ, người ta cần chờ bằng chứng ZK. Việc tạo bằng chứng ZK cần có thời gian và ngoài ra, có động cơ trì hoãn hơn nữa để bao gồm nhiều giao dịch hơn trong một bằng chứng duy nhất nhằm phân bổ tốt hơn chi phí tạo và xác minh bằng chứng.

Các kỹ thuật tổng hợp bằng chứng đưa ra giải pháp cho sự cân bằng giữa thời gian xác nhận và khấu hao chi phí: ngay cả khi một đợt tổng hợp có hoạt động tối thiểu, nó vẫn có thể được hưởng lợi từ việc khấu hao bằng cách bao gồm các giao dịch từ các đợt tổng hợp tích cực hơn trong cùng một bằng chứng. Một ví dụ về phương pháp này là SHARP của Starkware, hiện đang tổng hợp các bằng chứng từ các bản tổng hợp Starknet, Paradex và StarkEx như dYdX và thậm chí cả Validium.

Nơi mọi thứ trở nên phức tạp

Thông số phái sinh tổng hợp

Nếu tổng số không dựa trên, thì thứ tự phái sinh của các lô có thể được xác định bằng trình sắp xếp tổng hợp, có thể xuất bản chúng theo thứ tự khác trên L1.

Để cung cấp một ví dụ, chuỗi OP Stack xuất bản các lô trên L1 được liên kết bằng cách sử dụng hàm băm của lô trước đó. Các lô này không cần phải được xuất bản theo thứ tự thời gian, dẫn đến khoảng thời gian sắp xếp thứ tự 12 giờ trong đó các nút chờ các giao dịch có thể bị thiếu. Các giao dịch không nên được xem xét đưa vào chỉ vì chúng được xuất bản trên L1: nếu một lô chưa được kết nối với chuỗi lô chuẩn, thì có nguy cơ một phân nhánh thay thế với thứ tự hoặc tập hợp giao dịch khác sẽ được xây dựng.

Trên chuỗi OP Stack, thời gian tạo khối là 2 giây, tạo ra 6 khối trong mỗi khối Ethereum. Nhóm 6 khối này giữa các khối Ethereum được gọi là “kỷ nguyên”. Các tin nhắn L1-to-L2 được gửi qua L1 được bao gồm trong phần đầu tiên của khối đầu tiên của kỷ nguyên tương ứng đối với khối L1 đã cho. Mặc dù các giao dịch này có thể được coi là xác nhận mà không cần đợi cửa sổ tuần tự đi qua, vì thứ tự của chúng trong sổ cái L2 khi dẫn xuất đã được biết, điều quan trọng cần lưu ý là các nút sẽ không bắt đầu tính toán các khối chứa các thông báo này nếu thiếu lô trước đó. Điều này là do trạng thái không thể được tính toán nếu không có chuỗi hoàn chỉnh và do đó, gốc trạng thái cũng sẽ không được xuất bản trên L1.

Hậu quả của việc này là việc chỉ kiểm tra dữ liệu trên chuỗi là không đủ để theo dõi thời gian xác nhận L1. Cũng cần phải hiểu cách các khối L2 được lấy từ dữ liệu L1 bằng cách kiểm tra chính phần mềm nút tổng hợp.

Các chức năng được phép

Scroll là một bản tổng hợp ZK đăng dữ liệu giao dịch, nghĩa là về nguyên tắc, người ta không cần phải đợi bằng chứng ZK để coi giao dịch của họ là cuối cùng. Điều này sẽ đúng nếu họ không triển khai chức năng xóa các lô chưa được chứng minh.

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

Điều tương tự cũng có thể áp dụng cho các bản tổng hợp đăng khác biệt trạng thái: zkSync Era và zkSync Lite có quy trình ba bước để đăng khác biệt trạng thái: đầu tiên, họ cam kết dữ liệu mà không có bất kỳ bằng chứng nào, sau đó họ cung cấp bằng chứng cho họ và sau đó, sau 24 giờ trì hoãn , thư mục gốc sẽ có sẵn để thực thi nhằm xử lý việc rút tiền. Về lý thuyết, khi bằng chứng được cung cấp, thứ tự của các giao dịch là cố định, do đó người ta không cần đợi độ trễ thực hiện trôi qua. Ngoại trừ, zkSync có thể hoàn nguyên các khối đó:

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

Mặc dù đối với Kỷ nguyên zkSync, chưa có khối nào được hoàn nguyên, nhưng trên zkSync Lite, điều đó đã xảy ra 8 lần.

Khả năng quan sát cuối cùng

Vì các khác biệt về trạng thái đăng tổng hợp không đăng dữ liệu giao dịch, làm cách nào chúng tôi có thể theo dõi rằng một giao dịch thực sự đã được đưa vào? Có, chúng tôi có thể theo dõi các hiệu ứng, chẳng hạn như số lần sử dụng tài khoản, nhưng trường hợp chung sẽ phức tạp hơn. Một tháng trước tôi đã hỏi câu hỏi sau:

Chúng ta hãy xem một số câu trả lời:

Đây là một giải pháp hiệu quả nếu trình sắp xếp thứ tự sẵn sàng phản hồi cho bạn và nếu bạn tin tưởng nó. Nếu không thì sao? Hoặc nếu có nhưng bạn không tin tưởng thì sao? Làm thế nào để bạn xác minh rằng yêu cầu bồi thường là chính xác?

Câu trả lời yêu thích của tôi.

Một giải pháp thực sự hiệu quả đã được đề xuất ở đây:

trong khi điều này hoạt động, điều đó có nghĩa là quyết định kỹ thuật về việc sử dụng khác biệt trạng thái sẽ rò rỉ vào logic ứng dụng, nghĩa là ngay cả khi bản tổng hợp tương đương với EVM, các dự án vẫn phải điều chỉnh hợp đồng của họ cho phù hợp với việc xem xét này.

Giải pháp một phần là đăng gốc giao dịch và xác minh tính hợp lệ của chúng bên trong bằng chứng ZK. Tuy nhiên, ngay cả trong trường hợp này, người ta phải dựa vào trình sắp xếp chuỗi để có được đường dẫn Merkle cần thiết, điều này có thể hợp lý với các trình sắp xếp chuỗi tập trung có uy tín, nhưng sẽ phức tạp hơn trong môi trường không được phép.

Chỉ số sinh động

Là bước đầu tiên hướng tới việc theo dõi thời gian đến giai đoạn cuối cùng của các giao dịch tổng hợp, trên L2BEAT, chúng tôi đã bắt đầu theo dõi các số liệu về mức độ tồn tại, trong các khoảng thời gian cụ thể giữa các lô giao dịch (nếu có) và gốc trạng thái. Lý do là nếu một bản tổng hợp chẳng hạn, tương tác với L1 chỉ một lần mỗi tháng, thì người dùng không thể mong đợi thời gian tính đến lần cuối theo thứ tự phút. Số liệu về mức độ hoạt động có thể được coi là một chỉ báo giới hạn dưới về thời gian đến thời điểm cuối cùng: nếu tổng hợp dữ liệu giao dịch được đăng các đợt hai phút một lần và giả sử rằng việc phân phối các giao dịch L2 là đồng đều thì thời gian dự kiến đến thời điểm cuối cùng không thấp hơn một phút .

Dưới đây là một số ví dụ về dữ liệu mà chúng tôi đang theo dõi cho Kỷ nguyên zkSync (cập nhật trạng thái) và OP Mainnet (lô tx):

Số liệu về độ hoạt động của Kỷ nguyên zkSync trong tháng 9.

Số liệu về hoạt động của OP Mainnet trong tháng 9.

Đúng như dự đoán, do cần có thời gian để tạo bằng chứng ZK và có động cơ bao gồm nhiều giao dịch hơn trong một bằng chứng duy nhất, zkSync Era có số liệu về mức độ hoạt động kém hơn OP Mainnet. Điều quan trọng cần lưu ý là, như chúng ta đã thảo luận trong các phần trước, số liệu về mức độ hoạt động không chuyển trực tiếp sang các cân nhắc về tính cuối cùng: trong trường hợp xấu nhất, OP Mainnet thực sự có thời gian cao hơn để có được kết thúc cuối cùng do khoảng thời gian sắp xếp theo trình tự của nó.

Giờ đây, bạn có thể khám phá các số liệu về mức độ hoạt động cho hầu hết các bản tổng hợp trên L2BEAT:

Hạn chế của việc theo dõi sự sống động

Mặc dù mức độ sống động có thể được coi là một chỉ báo giới hạn dưới cho tính hữu hạn, nhưng đôi khi nó có thể là một chỉ số rất tệ. Hãy tưởng tượng một đợt tổng hợp có thời gian khối là 4 giây, nghĩa là với mỗi khối Ethereum có 3 khối tổng hợp. Nếu nhà điều hành tổng hợp chỉ đăng hai khối L2 cho mỗi khối L1, ngay cả khi theo quan điểm của Ethereum thì quá trình tổng hợp vẫn còn rất trực tiếp, nó sẽ ngày càng tụt hậu so với các xác nhận mềm L2 và thời gian đến giai đoạn cuối cùng sẽ ngày càng tồi tệ hơn. Mặc dù đây là một tình huống cực đoan nhưng đó là điều mà các bản tổng hợp cần phải tính đến.

Một ví dụ thực tế là Starknet: mặc dù chúng tôi quan sát thấy trung bình giữa các lần cập nhật trạng thái là 32 giây, thời gian đến trạng thái cuối cùng thực tế là gần 6 giờ:

Nguồn: starkscan.co

Điều này là do Starknet xuất bản bản cập nhật gốc trạng thái cho từng khối L2 trên L1. Tuy nhiên, để làm điều này, họ phải tham khảo bằng chứng SHARP, thường được đăng khoảng 30 phút một lần. Ngoài ra, các bằng chứng này chậm hơn khoảng 6 giờ so với đầu chuỗi xác nhận mềm L2.

Xác nhận mềm

Xác nhận mềm là các quy tắc xác nhận được sử dụng để đạt được thời gian xác nhận ngắn hơn trên L2 với chi phí đảm bảo an toàn. Hiện tại, trong mọi trường hợp, xác nhận mềm ngụ ý tin tưởng vào nhà điều hành tập trung không đăng các tx khác nhau trên L1. Xác nhận phần mềm không chính xác là các lỗi có thể quy ra, do đó, các cơ chế theo dõi danh tiếng của trình sắp xếp chuỗi ngoài chuỗi hoặc cắt giảm trên chuỗi có thể được triển khai. Phối hợp với Nethermind, chúng tôi có kế hoạch ước tính các thuộc tính bảo mật đó và theo dõi lượng giá trị có nguy cơ xảy ra tại bất kỳ thời điểm nào.

Bên trái: đảm bảo kinh tế cho Starknet nếu họ có xác nhận mềm được bảo đảm bằng cơ chế cắt giảm. Đúng: tổng giá trị có nguy cơ bị tái cấu trúc theo thời gian.

Tiến về phía trước

Theo dõi thời gian đến khi kết thúc là một nhiệm vụ phức tạp. Bước đầu tiên của chúng tôi là giám sát khoảng thời gian gửi bằng chứng cho các bản tổng hợp ZK, áp đặt giới hạn dưới cao hơn về thời gian đến thời điểm cuối cùng so với khoảng thời gian giữa các lần gửi gốc trạng thái. Sau đó, chúng tôi dự định giới thiệu các biểu đồ hiển thị dữ liệu lịch sử cho từng dự án. Sau đó, nghiên cứu của chúng tôi sẽ tập trung vào tất cả các cơ chế bổ sung cần được xem xét để cuối cùng đạt được các số liệu thời gian thực về thời gian tính đến thời điểm cuối cùng. Giữ nguyên!

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [Medium]. Mọi bản quyền đều thuộc về tác giả gốc [Luca Donno]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.