Vitalik mới viết: Làm cách nào để rút ngắn thời gian xác nhận giao dịch của Ethereum?
Tuyển chọn TechFlowTuyển chọn TechFlow
Vitalik mới viết: Làm cách nào để rút ngắn thời gian xác nhận giao dịch của Ethereum?
Giải pháp duy nhất cho các ứng dụng cần thời gian xác nhận ngắn hơn là kiến trúc slot-and-epoch.
Chuyên sâu báo cáo Web3Tác giả: Vitalik Buterin, đồng sáng lập Ethereum
Biên dịch: Luffy, Foresight News
Một đặc điểm thiết yếu cho trải nghiệm người dùng tốt trên blockchain là thời gian xác nhận giao dịch nhanh chóng. Ethereum hiện nay đã tiến bộ rất nhiều so với năm năm trước nhờ thời gian tạo khối ổn định sau EIP-1559 và chuyển sang PoS, các giao dịch mà người dùng gửi trên L1 có thể được xác nhận đáng tin cậy trong khoảng 5-20 giây, gần đạt đến trải nghiệm thanh toán bằng thẻ tín dụng. Tuy nhiên, trải nghiệm người dùng của Ethereum vẫn cần cải thiện thêm, vì một số ứng dụng thực sự yêu cầu độ trễ giao dịch chỉ vài trăm mili giây hoặc thậm chí ngắn hơn. Bài viết này sẽ giới thiệu một số giải pháp thực tế để tăng tốc độ xác nhận giao dịch trên Ethereum.
Tổng quan về các ý tưởng và công nghệ hiện tại
Tính dứt khoát trong một slot (Single Slot Finality)
Hiện nay, cơ chế đồng thuận Gasper của Ethereum sử dụng cấu trúc gồm slot và epoch. Cứ sau mỗi 12 giây (độ dài của một slot), một tập hợp con các trình xác thực sẽ bỏ phiếu cho khối mới nhất trên chuỗi khối. Trong vòng 32 slot (6,4 phút, một epoch gồm 32 slot), tất cả các trình xác thực đều có cơ hội bỏ phiếu một lần. Sau đó, những lá phiếu này được diễn giải lại như các thông điệp trong cơ chế đồng thuận kiểu PBFT, cung cấp đảm bảo kinh tế rất chặt chẽ sau hai epoch (12,8 phút), đây chính là tính dứt khoát (finality).
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 này. Nguyên nhân chính là: (i) nó quá phức tạp, tồn tại nhiều lỗi tương tác giữa cơ chế bỏ phiếu theo từng slot và cơ chế dứt khoát theo từng epoch; (ii) 12,8 phút là quá lâu, chẳng ai muốn chờ lâu đến vậy.
Tính dứt khoát trong một slot (single slot finality - SSF) thay thế kiến trúc này bằng một cơ chế tương tự như đồng thuận Tendermint, trong đó khối N đã hoàn tất trước khi khối N+1 được tạo ra. Điểm khác biệt chính so với Tendermint là chúng ta vẫn giữ lại cơ chế "rò rỉ do không hoạt động (inactivity leak)", cho phép chuỗi tiếp tục vận hành và khôi phục ngay cả khi hơn 1/3 trình xác thực ngoại tuyến.
Sơ đồ thiết kế của phương án tính dứt khoát trong một slot
Thách thức chính của SSF dường như là nó ngụ ý rằng mỗi người đặt cược trên Ethereum cần phải phát hành hai thông điệp mỗi 12 giây, điều này gây áp lực lớn lên chuỗi. Có một số ý tưởng thông minh giúp giảm nhẹ tình trạng này, bao gồm đề xuất Orbit SSF gần đây (https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928). Dù vậy, giải pháp này dù cải thiện trải nghiệm người dùng rõ rệt bằng cách tăng tốc "tính dứt khoát", nhưng nó không rút ngắn thời gian người dùng phải chờ 5-20 giây.
Xác nhận trước trên Rollup
Trong vài năm qua, Ethereum luôn theo đuổi lộ trình lấy Rollup làm trung tâm, thiết kế lớp nền tảng Ethereum (L1) nhằm hỗ trợ khả năng sẵn sàng dữ liệu và các chức năng khác. Những chức năng này được sử dụng bởi các giao thức L2 như Rollup (cũng như Validium và Plasma), cho phép cung cấp mức độ bảo mật tương đương Ethereum cho người dùng, nhưng quy mô giao dịch lớn hơn nhiều so với L1.
Điều này tạo ra sự phân tách mối quan tâm trong hệ sinh thái Ethereum: L1 Ethereum có thể tập trung vào chống kiểm duyệt, đáng tin cậy, ổn định và duy trì, cải thiện một số chức năng cốt lõi, trong khi L2 có thể tập trung vào trải nghiệm người dùng thông qua các cân nhắc văn hóa và kỹ thuật khác nhau. Nhưng nếu bạn đi theo hướng này, sẽ xuất hiện một câu hỏi không thể tránh khỏi: L2 nên tập trung vào việc phục vụ những người dùng muốn có xác nhận nhanh hơn trong vòng 5-20 giây.
Cho đến nay, việc xây dựng mạng "sắp xếp phi tập trung" riêng đã trở thành trách nhiệm không thể thoái thác của L2. Có thể cứ sau vài trăm mili giây, một nhóm nhỏ trình xác thực sẽ ký vào khối, đồng thời đặt cược token của họ vào các khối đó. Cuối cùng, tiêu đề khối của các khối L2 này sẽ được đăng lên L1.
Tập hợp trình xác thực L2 có thể gian lận: họ có thể ký vào khối B1, rồi sau đó ký vào khối B2 mâu thuẫn với B1 và nộp B2 lên chuỗi trước. Nhưng nếu họ làm vậy, họ sẽ bị phạt mất khoản tiền đặt cọc. Trên thực tế, chúng ta đã thấy phiên bản tập trung của cách làm này, nhưng các Rollup đang tiến triển chậm trong việc phát triển mạng sắp xếp phi tập trung. Bạn có thể nói rằng yêu cầu mọi L2 phải thực hiện sắp xếp phi tập trung là một thỏa thuận bất công: điều đó giống như yêu cầu Rollup làm công việc tương đương với việc tạo ra một L1 hoàn toàn mới. Vì một số lý do, nhà nghiên cứu Quỹ Ethereum Justin Drake đã thúc đẩy một phương pháp cho phép mọi L2 (và cả L1) truy cập vào cơ chế xác nhận trước chia sẻ của Ethereum: based preconfirmations.
Based preconfirmations (Xác nhận trước Based)
Phương pháp based preconfirmations giả định rằng người đề xuất khối Ethereum sẽ trở thành các bên tham gia cực kỳ phức tạp do các nguyên nhân liên quan đến MEV (xem đây để hiểu giải thích của tôi về MEV, xem thêm đề xuất). Phương pháp based preconfirmations tận dụng sự phức tạp này để khuyến khích những người đề xuất trưởng thành này cung cấp dịch vụ xác nhận trước.
Ý tưởng cơ bản là tạo ra một giao thức chuẩn hóa, theo đó người dùng có thể trả thêm phí để đổi lấy đảm bảo tức thì rằng giao dịch của họ sẽ được đưa vào khối tiếp theo, cùng với tuyên bố về kết quả thực thi giao dịch đó. Nếu người đề xuất vi phạm cam kết với bất kỳ người dùng nào, họ sẽ bị xử phạt.
Như đã nói ở trên, cơ chế based preconfirmations cung cấp đảm bảo cho các giao dịch L1. Nếu Rollup là một "Based Rollup" (chú thích: Based Rollup do Justin Drake đề xuất vào tháng 3 năm 2023, là loại Rollup mà việc sắp xếp hoàn toàn do L1 thực hiện), thì mọi khối L2 đều là giao dịch L1, do đó có thể sử dụng cơ chế tương tự để cung cấp xác nhận trước cho bất kỳ L2 nào.
Chúng ta thực sự đang thấy điều gì?
Giả sử chúng ta triển khai tính dứt khoát trong một slot. Chúng ta sử dụng các kỹ thuật tương tự Orbit để giảm số lượng trình xác thực ký tên trong mỗi slot, do đó cũng có thể giảm mức tối thiểu đặt cược 32 ETH, thật là一举 lưỡng tiện. Kết quả là, thời gian slot có thể dần tăng lên 16 giây. Sau đó, chúng ta sử dụng xác nhận trước trên Rollup hoặc based preconfirmations để cung cấp đảm bảo nhanh hơn cho người dùng. Bây giờ chúng ta có được điều gì? Một kiến trúc epoch-and-slot.
Câu nói "chúng là cùng một hình ảnh" đã bị lạm dụng quá mức, vì vậy tôi chỉ đơn giản đặt cạnh nhau một biểu đồ cũ mà tôi vẽ vài năm trước với biểu đồ xác nhận trước L2 để mô tả kiến trúc slot-and-epoch của Gasper, tôi hy vọng tôi có thể giải thích rõ ràng.
Có một lý do triết học sâu sắc giải thích tại sao mọi người luôn không thể tránh khỏi việc sử dụng kiến trúc epoch-and-slot: đạt được sự đồng thuận gần đúng về một vấn đề về cơ bản cần ít thời gian hơn so với đạt được sự đồng thuận tối đa về "tính dứt khoát kinh tế".
Một lý do đơn giản là số lượng nút. Mặc dù do việc tối ưu hóa BLS và ZK-STARK trong tương lai gần, mối quan hệ đánh đổi truyền thống giữa phi tập trung / thời gian dứt khoát / chi phí giờ đây trông nhẹ nhàng hơn, nhưng về bản chất, các quan điểm sau vẫn đúng:
-
"Sự đồng thuận gần đúng" chỉ cần một số lượng nhỏ nút, trong khi tính dứt khoát kinh tế cần một phần đáng kể trong tổng số tất cả nút.
-
Một khi số lượng nút vượt quá một ngưỡng nhất định, bạn sẽ cần thêm thời gian để thu thập chữ ký.
Trong Ethereum hiện tại, slot 12 giây được chia thành ba sub-slot dành cho (i) phát hành và phân phối khối, (ii) chứng minh (attestation), (iii) tập hợp chứng minh. Nếu số lượng người chứng minh ít hơn nhiều, chúng ta có thể rút xuống còn hai sub-slot và có thời gian slot 8 giây. Một yếu tố quan trọng khác trên thực tế là "chất lượng" của các nút. Nếu chúng ta cũng có thể dựa vào một tập hợp con chuyên biệt của các nút để đạt được sự đồng thuận gần đúng (và vẫn sử dụng tập hợp đầy đủ các trình xác thực để đạt được tính dứt khoát), chúng ta có thể hợp lý rút ngắn thời gian xuống khoảng 2 giây.
Do đó, tôi cho rằng (i) kiến trúc slot-and-epoch rõ ràng là đúng đắn, nhưng (ii) không phải mọi kiến trúc slot-and-epoch đều giống nhau, chúng ta cần khám phá không gian thiết kế một cách đầy đủ hơn. Đặc biệt, những phương án không đan xen chặt chẽ như Gasper đáng được nghiên cứu.
L2 nên làm gì?
Theo tôi, hiện tại L2 có thể theo đuổi ba chiến lược hợp lý:
-
Hoàn toàn "based" cả về mặt kỹ thuật lẫn tinh thần. Nghĩa là, L2 là kênh truyền tải tốt hơn cho các thuộc tính kỹ thuật và giá trị của lớp nền tảng Ethereum (phi tập trung cao, chống kiểm duyệt, v.v.). Theo cách đơn giản nhất, bạn có thể coi các Rollup này như "phân mảnh thương hiệu", nhưng chúng cũng có thể tham vọng hơn nhiều, và tiến hành thử nghiệm mạnh mẽ về thiết kế máy ảo mới và các cải tiến kỹ thuật khác.
-
Trở thành "máy chủ với khung sườn blockchain", và tận dụng tối đa điều đó. Nếu bạn bắt đầu từ một máy chủ, sau đó thêm vào (i) bằng chứng hiệu lực STARK để đảm bảo máy chủ tuân thủ quy tắc, (ii) quyền cho người dùng rút ra hoặc buộc thực hiện giao dịch, và có thể (iii) quyền lựa chọn tập thể, thông qua việc rút hàng loạt có phối hợp hay khả năng bỏ phiếu thay đổi trình sắp xếp, thì bạn đã có được rất nhiều lợi ích của chuỗi, đồng thời vẫn giữ được hiệu quả phần lớn của máy chủ.
-
Giải pháp dung hòa: một chuỗi nhanh với 100 nút, dựa vào 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 của nhiều dự án L2.
Đối với một số ứng dụng (ví dụ như ENS, kho lưu trữ khóa, và một số trường hợp thanh toán), thời gian khối 12 giây là đủ. Đối với các ứng dụng cần thời gian xác nhận ngắn hơn, giải pháp duy nhất là kiến trúc slot-and-epoch. Trong cả ba trường hợp này, "epoch" đều là SSF của Ethereum (có lẽ chúng ta có thể định nghĩa lại cụm từ viết tắt này thành thứ gì đó khác ngoài "single slot", ví dụ như "Secure Speedy Finality"). Tuy nhiên, trong cả ba trường hợp trên, "slot" là khác nhau:
-
Kiến trúc slot-and-epoch gốc của Ethereum
-
Xác nhận trước trên máy chủ
-
Xác nhận trước trên ủy ban
Một vấn đề then chốt là: chúng ta có thể làm tốt đến đâu với thứ thuộc loại (1)? Đặc biệt, nếu nó trở nên cực kỳ tốt, thì dường như loại (3) sẽ trở nên vô nghĩa. Loại (2) sẽ luôn tồn tại, vì bất kỳ thứ gì "based" đều không phù hợp với L2 dữ liệu off-chain như Plasma và Validium. Nhưng nếu kiến trúc slot-and-epoch gốc của Ethereum có thể rút ngắn thời gian "slot" (tức là xác nhận trước) xuống còn 1 giây, thì không gian cho loại (3) sẽ thu hẹp rất nhiều.
Ngày nay, chúng ta vẫn còn xa mới có được câu trả lời cuối cùng cho những câu hỏi này. Người đề xuất khối sẽ trở nên phức tạp đến mức nào? Câu trả lời cho câu hỏi then chốt này vẫn còn nhiều bất định. Các thiết kế như Orbit SSF rất mới mẻ, do đó không gian thiết kế cho các phương án slot-and-epoch kiểu Orbit SSF cần được khám phá thêm. Chúng ta có càng nhiều lựa chọn, chúng ta càng có thể làm tốt hơn cho người dùng trên L1 và L2, đồng thời giúp đơn giản hóa công việc của các nhà phát triển L2.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@VitalikButerin
