*Chuyển tiếp Tiêu đề Gốc 'Epochs and slots all the way down: cách giúp người dùng Ethereum có thời gian xác nhận giao dịch nhanh hơn'

Một trong những tính chất 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 chóng. Hiện nay, Ethereum đã cải thiện rất nhiều so với năm năm trước. Cảm ơn sự kết hợp củaEIP-1559và thời gian khối ổn định sauGộp, các giao dịch được gửi bởi người dùng trên L1 đáng tin cậy xác nhận trong vòng 5-20 giây. Điều này xấp xỉ cạnh tranh với trải nghiệm thanh toán bằng thẻ tín dụng. Tuy nhiên, có giá trị trong việc cải thiện trải nghiệm người dùng hơn nữa, và có một số ứng dụng yêu cầu độ trễ trên hàng trăm mili giây hoặc thấp hơn. Bài đăng này sẽ đi qua một số tùy chọn thực tế mà Ethereum có.

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

Độ chắc chắn cuối cùng của một khe đơn

Hôm nay, Ethereum’s Gasperconsensus sử dụng một kiến trúc slot và epoch. Mỗi slot kéo dài 12 giây, một tập hợp con của các validators đăng một phiếu bầu về đầu của chuỗi, và trong suốt 32 slots (6.4 phút), tất cả các validators đều có cơ hội bỏ phiếu một lần. Những phiếu bầu này sau đó được hiểu lại như là các tin nhắn trong một cách mập mờ. PBFT-likethuật toán đồng thuận, sau hai epoch (12,8 phút) cung cấp một đảm bảo kinh tế rất khó gọi là tính cuối cùng.

Trong những năm gần đây, chúng tôi càng ngày càng không thoải mái với phương pháp hiện tại. Những lý do chính là (i) nó phức tạp và có nhiều lỗi tương tác giữa cơ chế bỏ phiếu từng khe và cơ chế sự hoàn thành từng kỷ lục, và (ii) 12,8 phút quá lâu và không ai quan tâm đến đợi lâu như vậy.

Tính cuối cùng của một khe thay thế kiến trúc này bằng một cơ chế tương tự như Sự đồng thuận Tenderminttrong đó khối N được hoàn thiện trước khi tạo khối N+1. Sự khác biệt chính so với Tendermint là chúng tôi giữ lại “rò rỉ không hoạt động“ cơ chế, cho phép chuỗi tiếp tục hoạt động và phục hồi nếu hơn 1/3 số lượng người xác minh offline.

Một biểu đồ về đề xuất hàng đầuthiết kế độ chắc chắn đơn lẻ_

Thách thức chính với SSF là về mặt ngây thơ, dường như ngụ ý rằng mỗi người Ethereum đặt cược sẽ cần phải xuất bản hai tin nhắn mỗi 12 giây, điều này sẽ làm tải nặng cho chuỗi xử lý. Có ý tưởng thông minhđể giảm thiểu điều này, bao gồm cả gần đây nhấtOrbit SSFđề xuất. Nhưng ngay cả khi điều này cải thiện UX đáng kể bằng cách làm cho “tính chất cuối cùng” đến nhanh hơn, điều này vẫn không thay đổi thực tế là người dùng cần phải chờ đợi 5-20 giây.

Xác nhận trước Rollup

Trong vài năm qua, Ethereum đã theo đuổi mộtlộ trình tập trung vào rollup, thiết kế lớp cơ sở Ethereum (L1) xung quanh việc hỗ trợ sẵn sàng dữ liệuvà các chức năng khác sau đó có thể được sử dụng bởi các giao thức tầng 2 như rollups(nhưng cũngvalidiumsvàplasmas) có thể cung cấp cho người dùng cùng mức độ bảo mật như Ethereum, nhưng với quy mô cao hơn nhiều.

Điều này tạo ra một phân tách quan tâmtrong hệ sinh thái Ethereum: Ethereum L1 có thể tập trung vào việc chống kiểm duyệt, đáng tin cậy, ổn định và duy trì và cải thiện một lõi chức năng cơ bản cụ thể, và L2 có thể tập trung vào tiếp cận trực tiếp với người dùng - cả hai thông qua cácvăn hóavà sự đánh đổi công nghệ. Nhưng nếu bạn đi theo con đường này, một vấn đề không thể tránh khỏi nảy sinh: L2 muốn phục vụ người dùng muốn xác nhận giao dịch nhanh hơn rất nhiều so với 5-20 giây.

Cho đến nay, ít nhất trong lý thuyết, đã là trách nhiệm của L2s để tạo ra mạng lưới "decentralized sequencing" riêng của họ. Một nhóm nhỏ các người xác minh sẽ ký duyệt các khối, có thể là mỗi vài trăm mili giây, và họ sẽ đặt "stake" của mình vào những khối đó. Cuối cùng, tiêu đề của những khối L2 này được xuất bản lên L1.

Các bộ xác thực L2 có thể gian lận: trước tiên họ có thể ký khối B1, sau đó ký một khối B2 xung đột và cam kết nó vào chuỗi trước B1. Nhưng nếu họ làm điều này, họ sẽ bị bắt và mất tiền gửi. Trong thực tế, chúng tôi đã thấy các phiên bản tập trung của điều này, nhưng các bản tổng hợp đã chậm phát triển các mạng trình tự phi tập trung. Và bạn có thể lập luận rằng việc yêu cầu tất cả các L2 thực hiện trình tự phi tập trung là một thỏa thuận không công bằng: chúng tôi yêu cầu các bản tổng hợp về cơ bản thực hiện hầu hết các công việc tương tự như tạo ra một L1 hoàn toàn mới. Vì lý do này và những lý do khác, Justin Drake đã thúc đẩy một cách để cung cấp cho tất cả các L2 (cũng như L1) quyền truy cập vào cơ chế xác nhận trước trên toàn Ethereum được chia sẻ: dựa trên sự xác nhận trước.

Dựa trên việc xác nhận trước

Phương pháp xác nhận trước dựa trên giả định rằng người đề xuất Ethereum sẽ trở thành những diễn viên rất tinh vi cho những lý do liên quan đến MEV (xem ở đâycho giải thích của tôi về MEV, và xem thêmvé thực hiệnDòng đề xuất). Phương pháp xác nhận trước dựa trên sự tinh tế này bằng cách khuyến khích những người đề xuất tinh vi 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 là tạo ra một giao thức tiêu chuẩn mà người dùng có thể đề xuất một khoản phí bổ sung để đảm bảo ngay lập tức giao dịch sẽ được bao gồm trong khối tiếp theo, cùng với có thể là một yêu cầu về kết quả của việc thực thi giao dịch đó. Nếu người đề xuất vi phạm bất kỳ lời hứa nào mà họ đưa ra cho bất kỳ người dùng nào, họ có thể bị trừ tài sản.

Như đã mô tả, xác nhận trước dựa trên cơ sở cung cấp bảo đảm cho các giao dịch L1. Nếu rollups thì...“based”, sau đó tất cả các khối L2 đều là giao dịch L1, và 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.

Chúng ta đang nhìn vào cái gì thật sự ở đây?

Giả sử rằng chúng ta triển khai tính chất hoàn thành trong một khe đơn.Orbit-like kỹ thuật để giảm số lượng người xác nhận trong mỗi slot, nhưng không quá nhiều, để chúng ta cũng có thể tiến bộ trong mục tiêu chính là giảm tối thiểu 32 ETH cần đặt cược. Kết quả, có thể thời gian slot tăng lên, lên đến 16 giây. Sau đó, chúng tôi sử dụng các phiên bản trước xác nhận hoặc các phiên bản dựa trên để đảm bảo cho người dùng nhanh hơn. Hiện tại chúng ta có gì? Một kiến trúc epoch-và-slot.

Meme “hình ảnh của họ giống nhau” đang được sử dụng rất nhiều lần ở thời điểm này, vì vậy tôi chỉ đưa một sơ đồ cũ tôi đã vẽ nhiều năm trước để mô tả kiến trúc khe và kỷ nguyên của Gasper và một sơ đồ xác nhận trước L2 cạnh nhau, và hy vọng điều đó sẽ truyền đạt được điểm.

Có một lý do triết học sâu sắc vì sao kiến trúc epoch-and-slot dường như khó tránh khỏi: nó tốt hơn về mặt thời gian để đạt được sự đồng thuận xấp xỉ về một điều gì đó, hơn là đạt được sự đồng thuận 'sự cuối cùng về mặt kinh tế' tối đa về nó.

Một lý do đơn giản là số lượng node. Trong khi cơ chế cũ tuyến tính...@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">decentralization / finality time / overhead tradeoff đang trở nên nhẹ hơn do việc tối ưu hóa BLS aggregation và trong tương lai gần, ZK-STARKs, điều này vẫn đúng về cơ bản là:

1. Chỉ cần một vài nút mạng để có được "thoả thuận xấp xỉ" trong khi tính kết thúc kinh tế yêu cầu một phần đáng kể của tất cả các nút mạng.
2. Một khi số lượng nút vượt quá một mức nhất định, bạn cần phải dành nhiều thời gian hơn để thu thập chữ ký.

Trong Ethereum ngày nay, một khe cắm 12 giây được chia thành ba vị trí phụ, để (i) xuất bản và phân phối khối, (ii) chứng thực và (iii) tổng hợp chứng thực. Nếu số lượng attester thấp hơn nhiều, chúng tôi có thể giảm xuống hai khe phụ và có thời gian khe 8 giây. Một yếu tố khác, và thực tế lớn hơn, 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 các nút được chuyên nghiệp hóa để thực hiện các thỏa thuận gần đúng (và vẫn sử dụng các trình xác thực đầy đủ được đặt cho tính cuối cùng), chúng ta có thể giảm xuống còn ~ 2 giây.

Do đó, với tôi, (i) kiến trúc slot-and-epoch là rõ ràng đúng, nhưng cũng (ii) không phải tất cả các kiến trúc slot-and-epoch đều được tạo ra bình đẳng, và có giá trị trong việc khám phá sâu hơn không gian thiết kế. Đặc biệt, đáng để khám phá các tùy chọn không chặt chẽ như Gasper, và thay vào đó có sự tách rời mạnh mẽ giữa hai cơ chế.

L2s nên làm gì?

Trong quan điểm của tôi, hiện tại có ba chiến lược hợp lý cho L2 thực hiện:

1. Hãy "dựa trên", cả về công nghệ và tinh thần. Đó là, chúng tối ưu hóa để trở thành ống dẫn truyền qua cho các thuộc tính kỹ thuật của lớp cơ sở Ethereum và các giá trị của nó (phân cấp cao, chống kiểm duyệt, v.v.). Ở dạng đơn giản nhất, bạn có thể nghĩ về những cuộn này là "phân đoạn có thương hiệu", nhưng chúng cũng có thể tham vọng hơn thế nhiều và thử nghiệm khá nhiều với các thiết kế máy ảo mới và các cải tiến kỹ thuật khác.
2. Tự hào là một “máy chủ với cơ sở hạ tầng 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 (i) chứng minh tính hợp lệ STARK để đảm bảo rằng máy chủ đang tuân thủ quy tắc, (ii) quyền được đảm bảo cho người dùng để thoát hoặc buộc các giao dịch, và có thể (iii) tự do lựa chọn tập thể, thông qua thoát tập trung đồng loạt hoặc thông qua khả năng bỏ phiếu để thay đổi sequencer, thì bạn đã thu được rất nhiều lợi ích của việc trên chuỗi, trong khi vẫn giữ được hầu hết hiệu quả của một máy chủ.
3. Tiếp cận thoả hiệp: một chuỗi nhanh gồm một trăm nút, với Ethereum cung cấp tính tương tác và an ninh bổ sung. Điều này là lộ trình hiện tại mặc định của nhiều dự án L2.

Đối với một số ứng dụng, (ví dụ như,ENS, keystores) some payments), một thời gian khối 12 giây là đủ. Đối với những ứng dụng không phải vậy, giải pháp duy nhất là kiến trúc slot-and-epoch. Trong tất cả ba trường hợp, “thời kỳ” là SSF của Ethereum (có lẽ chúng ta có thể sửa đổi viết tắt này để có nghĩa khác ngoài “single slot”, ví dụ, nó có thể là “Secure Speedy Finality”). Nhưng những “khe” lại khác nhau trong mỗi trường hợp trên:

1. Một kiến trúc khe cắm và thời kỷ native của Ethereum
2. Xác nhận trước máy chủ
3. Xác nhận trước của ủy ban

Một câu hỏi then chốt là, chúng ta có thể làm cho một cái gì đó trong danh mục (1) tốt đến đâu? Cụ thể, nếu nó trở nên thực sự tốt, thì cảm giác như danh mục (3) mất đi nhiều ý nghĩa. Danh mục (2) sẽ luôn tồn tại, ít nhất vì bất cứ điều gì “dựa” không hoạt động cho các L2 ngoại chuỗi dữ liệu như plasmas và validiums. Nhưng nếu một kiến trúc khe gốc và kỷ nguyên native của Ethereum có thể giảm xuống thời gian “khe” 1 giây (tức là thời gian trước khi xác nhận), thì không gian cho danh mục (3) trở nên nhỏ hơn khá nhiều.

Ngày nay, chúng ta còn lâu mới 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 - những người đề xuất khối sẽ trở nên tinh vi như thế nào - vẫn là một lĩnh vực có khá nhiều điều không chắc chắn. Các thiết kế như Orbit SSFrất gần đây, cho thấy không gian thiết kế của các thiết kế khe và kỷ nguyên nơi một cái gì đó như Orbit SSF là kỷ nguyên vẫn chưa được khám phá kỹ. Càng nhiều tùy chọn chúng ta có, chúng ta càng tốt cho người dùng cả trên L1 và trên L2s, và chúng ta càng đơn giản hóa công việc của các nhà phát triển L2.

Disclaimer：

1. Bài viết này được tái bản từ [vitalik].Chuyển tiếp tiêu đề ban đầu 'Kỷ nguyên và vị trí tất cả các cách xuống: các cách để cung cấp cho người dùng Ethereum thời gian xác nhận giao dịch nhanh hơn'. Tất cả bản quyền thuộc về tác giả gốc [vitalik*]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ Gate Họcđội ngũ và họ sẽ xử lý nhanh chóng.
2. Ối trời ơi: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không phải là bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của 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 đã được dịch là không được phép.