Tác giả gốc |Vitalik

Biên soạn | Odaily Planet Daily Nan Zhi

Một trong những thuộc tính quan trọng của trải nghiệm người dùng blockchain tốt là thời gian xác nhận giao dịch nhanh. Ngày nay, Ethereum đã được cải thiện rất nhiều so với 5 năm trước. Nhờ EIP-1559 và thời gian chặn ổn định sau khi chuyển sang PoS (The Merge), các giao dịch do người dùng gửi trên L1 thường có thể được xác nhận trong vòng 5-20 giây, gần tương đương với trải nghiệm thanh toán bằng thẻ tín dụng. Tuy nhiên, việc cải thiện hơn nữa trải nghiệm người dùng sẽ có giá trị và một số ứng dụng thậm chí còn yêu cầu độ trễ hàng trăm mili giây trở xuống. Bài viết này sẽ khám phá một số tùy chọn thiết thực để cải thiện thời gian xác nhận giao dịch trong Ethereum.

Tổng quan về các ý tưởng và kỹ thuật hiện có

tính hữu hạn của một khe duy nhất

Hiện tại, cơ chế đồng thuận Gasper của Ethereum sử dụng kiến ​​trúc một slot (Slot) và Epoch. Cứ sau 12 giây cho một vị trí, một tập hợp con người xác thực sẽ bỏ phiếu ở đầu chuỗi và cứ sau 32 vị trí (6,4 phút), tất cả người xác nhận đều có cơ hội bỏ phiếu một lần. Những phiếu bầu này sau đó được diễn giải lại dưới dạng thông điệp trong thuật toán đồng thuận tương tự như PBFT, mang lại sự đảm bảo kinh tế rất mạnh mẽ được gọi là tính hữu hạn sau hai Kỷ nguyên (12,8 phút).

Trong vài năm qua, chúng tôi ngày càng không hài lòng với cách tiếp cận hiện tại của mình. Có hai lý do chính dẫn đến điều này. Thứ nhất, phương pháp này phức tạp và có nhiều lỗi tương tác giữa cơ chế bỏ phiếu theo từng khe và cơ chế cuối cùng của Epoch-to-Epoch. Thứ hai, 12,8 phút là quá dài và không ai muốn. phải chờ đợi lâu như vậy.

Single Slot Finality (SSF) thay thế kiến ​​trúc này bằng cơ chế tương tự như sự đồng thuận của Tendermint, trong đó khối N được hoàn thiện trước khi khối N+1 được tạo. Sự khác biệt chính với Tendermint là chúng tôi giữ lại cơ chế "rò rỉ không hoạt động", cho phép chuỗi tiếp tục chạy và phục hồi nếu hơn 1/3 số trình xác thực ngoại tuyến.

Thách thức chính với tính hữu hạn của một khe duy nhất là nó có nghĩa là mỗi người đặt cược Ethereum cần xuất bản hai tin nhắn cứ sau 12 giây, đây là một tải trọng đáng kể trên chuỗi. Có một số ý tưởng thông minh để giảm thiểu vấn đề này, bao gồm cả đề xuất Orbit SSF gần đây. Mặc dù điều này tăng tốc đáng kể độ "cuối cùng" để cải thiện trải nghiệm người dùng, nhưng nó không thay đổi thực tế là người dùng cần đợi 5-20 giây.

Xác nhận trước tổng hợp

Ethereum đã đi theo lộ trình tập trung vào tổng hợp trong vài năm qua, thiết kế lớp cơ sở Ethereum (L1) để hỗ trợ tính khả dụng của dữ liệu và các tính năng khác, sau đó được cung cấp cho các giao thức L2 như tổng hợp, xác thực và plasma. cung cấp cho người dùng mức độ bảo mật tương tự như Ethereum trên quy mô lớn hơn.

Điều này tạo ra sự tách biệt các mối quan tâm trong hệ sinh thái Ethereum: Ethereum L1 tập trung vào khả năng chống kiểm duyệt, độ tin cậy, tính ổn định cũng như duy trì và cải thiện chức năng cốt lõi của một lớp cơ sở nhất định, trong khi L2 tập trung vào giao tiếp trực tiếp hơn thông qua các nền văn hóa và công nghệ khác nhau. tới người dùng. Nhưng nếu bạn đi theo con đường này, một vấn đề không thể tránh khỏi sẽ nảy sinh: L2 muốn cung cấp cho người dùng xác nhận nhanh hơn 5-20 giây.

Cho đến nay, ít nhất về mặt lý thuyết, trách nhiệm của L2 là tạo ra mạng lưới “trình tự sắp xếp phi tập trung” của riêng mình. Một nhóm nhỏ người xác nhận có thể ký các khối cứ sau vài trăm mili giây và đặt cược cổ phần của họ vào các khối đó. Cuối cùng, các tệp tiêu đề cho các khối L2 này được xuất bản lên L1.

Nhưng bộ trình xác thực L2 có thể phạm tội "lừa đảo": họ có thể ký khối B1 trước, sau đó ký khối B2 xung đột và cam kết nó vào chuỗi trước B1. Nhưng nếu làm vậy, họ sẽ bị bắt và mất tài sản cầm cố. Chúng tôi thực sự đã thấy các ví dụ thực tế về các phiên bản tập trung, nhưng mặt khác, việc triển khai các mạng đặt hàng phi tập trung lại diễn ra chậm chạp. Bạn có thể lập luận rằng thật không công bằng khi yêu cầu tất cả các L2 phải được phân cấp: chúng tôi đang yêu cầu tổng hợp thực hiện công việc gần giống như tạo ra một L1 hoàn toàn mới. Do đó, Justin Drake đã và đang quảng bá một cách để tất cả L2 (cũng như L1) sử dụng cơ chế xác nhận trước được chia sẻ trên toàn Ethereum: xác nhận trước cơ bản.

Xác nhận trước cơ bản

Cách tiếp cận xác nhận trước dựa trên giả định rằng những người đề xuất Ethereum là những người tham gia rất tinh vi có liên quan đến MEV. Các phương pháp tiếp cận dựa trên xác nhận trước khai thác sự phức tạp này bằng cách khuyến khích những người đề xuất phức tạp này chấp nhận trách nhiệm cung cấp dịch vụ xác nhận trước.

Ý tưởng cơ bản của phương pháp này là tạo ra một giao thức được tiêu chuẩn hóa trong đó người dùng có thể cung cấp một khoản phí bổ sung để đảm bảo đảm bảo ngay lập tức rằng giao dịch sẽ được đưa vào khối tiếp theo, cũng như yêu cầu về kết quả thực hiện giao dịch đó. Nếu người đề xuất vi phạm bất kỳ lời hứa nào với bất kỳ người dùng nào, họ có thể bị loại.

Như đã nêu, giao dịch L1 được đảm bảo dựa trên xác nhận trước. Nếu tổng số là "dựa trên", thì tất cả các khối L2 đều là giao dịch L1, do đó, cơ chế tương tự có thể được sử dụng để cung cấp xác nhận trước cho bất kỳ L2 nào.

Thực ra chúng ta đang nhìn vào cái gì?

Giả sử chúng ta đạt được tính hữu hạn của một khe. Chúng tôi sử dụng công nghệ tương tự như Orbit để giảm số lượng người xác thực ký trên mỗi vị trí, nhưng không quá nhiều để chúng tôi cũng có thể đạt được tiến bộ trong mục tiêu chính là giảm mức đặt cược tối thiểu 32 ETH. Thời gian có thể tăng lên 16 giây và sau đó chúng tôi sử dụng xác nhận trước tổng hợp hoặc xác nhận trước cơ bản để cung cấp cho người dùng xác nhận nhanh hơn. Cuối cùng những gì chúng tôi nhận được: một kiến ​​trúc khe thời đại.

Có một lý do triết học sâu sắc khiến cho kiến ​​trúc thời đại và khe cắm dường như khó tránh khỏi: Mất ít thời gian hơn để thống nhất một cách đại khái về một điều gì đó so với việc đạt được thỏa thuận về một điều gì đó có mức độ "cuối cùng về kinh tế" lớn nhất.

Một lý do đơn giản là số lượng nút. Mặc dù sự phân cấp tuyến tính/thời gian cuối cùng/sự đánh đổi chi phí cũ hiện có vẻ nhẹ nhàng do tính năng tổng hợp BLS được tối ưu hóa cực cao và các ZK-STARK sắp ra mắt, nhưng không thể bỏ qua những lý do sau:

  • "Sự đồng thuận gần đúng" chỉ yêu cầu một số lượng nhỏ các nút, trong khi mục tiêu kinh tế cuối cùng đòi hỏi phần lớn các nút.

  • Khi số lượng nút vượt quá một kích thước nhất định, bạn cần dành nhiều thời gian hơn để thu thập chữ ký.

Trong Ethereum ngày nay, vị trí 12 giây được chia thành ba vị trí phụ: xuất bản và phân phối khối, chứng thực và tổng hợp chứng thực. Nếu số lượng người chuẩn bị giảm đáng kể, chúng ta có thể giảm xuống còn hai khe phụ và sử dụng thời gian khe 8 giây. Một yếu tố khác, thực tế hơn và lớn hơn là "chất lượng" của nút. Một yếu tố lớn hơn khác là "chất lượng" của nút. Nếu chúng ta cũng có thể dựa vào một tập hợp con các nút chuyên biệt để đạt được thỏa thuận gần đúng (và vẫn sử dụng bộ trình xác thực đầy đủ để xác định tính hữu hạn), thì chúng ta có thể giảm thời gian này xuống còn ~2 giây.

Vì vậy, theo tôi, kiến ​​trúc epoch-and-slot rõ ràng là đúng, nhưng không phải tất cả các kiến ​​trúc epoch-and-slot đều được tạo ra như nhau và có giá trị trong việc khám phá không gian thiết kế một cách đầy đủ hơn. Một hướng đáng được nghiên cứu sâu hơn không được kết hợp chặt chẽ như trong Gasper, mà có sự tách biệt mạnh mẽ hơn về mối quan tâm giữa hai cơ chế.

L2 nên làm gì?

Theo tôi hiện tại L2 có 3 chiến lược hợp lý:

  • “Dựa” cả về mặt kỹ thuật và tinh thần. Nghĩa là, họ tối ưu hóa các đặc tính kỹ thuật của lớp cơ sở Ethereum và các giá trị của nó (độ phân quyền cao, khả năng chống kiểm duyệt, v.v.). Ở dạng đơn giản nhất, bạn có thể coi những bản tổng hợp này là "các phân đoạn có thương hiệu", nhưng chúng cũng có thể tham vọng hơn nhiều, thử nghiệm nhiều thiết kế máy ảo mới và các cải tiến kỹ thuật khác.

  • Trở thành một “máy chủ có giàn giáo blockchain” và tận dụng tối đa nó. Nếu bạn bắt đầu với một máy chủ và sau đó thêm bằng chứng hợp lệ STARK để đảm bảo rằng máy chủ tuân thủ các quy tắc; để đảm bảo quyền rút tiền hoặc buộc giao dịch của người dùng và quyền tự do lựa chọn tập thể, thông qua việc rút tiền hàng loạt có phối hợp hoặc bằng cách thay đổi lệnh của người đặt hàng; bỏ phiếu, thì bạn đã có Nó đạt được hầu hết lợi ích của việc liên kết lên trong khi vẫn giữ được phần lớn hiệu quả của máy chủ.

  • Nền tảng trung gian: một chuỗi nhanh với hàng trăm nút, Ethereum cung cấp khả năng tương tác và bảo mật bổ sung. Đây là lộ trình thực tế hiện tại cho nhiều dự án L2.

Đối với một số ứng dụng (ví dụ: ENS, lưu trữ khóa, một số giao thức thanh toán), thời gian chặn 12 giây là đủ. Đối với những ứng dụng không áp dụng được điều này, giải pháp duy nhất là kiến ​​trúc epoch-and-slot. Trong ba trường hợp, "kỷ nguyên" là SSF của Ethereum, nhưng vị trí khác nhau trong mỗi trường hợp trong ba trường hợp trên:

  • Kiến trúc kỷ nguyên và vị trí gốc của Ethereum

  • Xác nhận trước máy chủ

  • xác nhận trước của ủy ban

Câu hỏi quan trọng là chúng ta có thể giỏi đến mức nào ở Loại 1? Đặc biệt, nếu nó thực sự tốt thì có cảm giác như Hạng 3 sẽ không còn ý nghĩa gì nhiều nữa. Bởi vì tất cả các giải pháp "dựa trên" không hoạt động với dữ liệu ngoài chuỗi L2 như plasma và validium nên loại 2 sẽ luôn tồn tại. Nếu kiến ​​trúc epoch-and-slot gốc của Ethereum có thể giảm xuống còn 1 giây thời gian, thì không gian dành cho Loại 3 sẽ trở nên nhỏ hơn nhiều.

Ngày nay, chúng ta còn lâu mới có được câu trả lời cuối cùng cho những câu hỏi này. Một câu hỏi quan trọng là những người đề xuất khối phức tạp sẽ trở nên như thế nào, đây vẫn là một lĩnh vực còn nhiều điều không chắc chắn. Các thiết kế như Orbit SSF rất mới lạ, vì vậy không gian thiết kế của các sơ đồ như sử dụng Orbit SSF làm kỷ nguyên trong epoch-and-slot vẫn đáng để khám phá đầy đủ. Càng có nhiều tùy chọn, chúng tôi càng có thể làm tốt hơn cho người dùng L1 và L2, đồng thời chúng tôi có thể giúp cuộc sống của các nhà phát triển L2 trở nên dễ dàng hơn.