Chuyển Tiếp Tiêu Đề Gốc 'Các Kỷ Nguyên Và Khe Cắm Tất Cả Cách Thức: Cách Để Cung Cấp Thời Gian Xác Nhận Giao Dịch Nhanh Hơn Cho Người Dùng Ethereum'

Một trong những đặc điểm 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. Điều này nhờ vào sự kết hợp củaEIP-1559và thời gian khối ổn định sauSự hợp nhất, các giao dịch được gửi bởi người dùng trên L1 thường xác nhận một cách đáng tin cậy trong vòng 5-20 giây. Điều này khá cạnh tranh 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 trải nghiệm người dùng hơn còn có giá trị, và có một số ứng dụng đòi hỏi thời gian trễ trong khoảng vài trăm mili giây hoặc thậm chí ít hơn. Bài viết này sẽ đi qua một số lựa chọn thực tế mà Ethereum có.

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

Khe cắm duy nhất cuối cùng

Hôm nay, Ethereum củaGasperconsensus sử dụng kiến trúc khe và kỷ nguyên. Mỗi khe 12 giây, một phần nhỏ các xác minh viên công bố một phiếu bầu về đầu chuỗi, và trong khoảng 32 khe (6,4 phút), tất cả các xác minh viên 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ơ hồ Giống PBFTThuật toán đồng thuận, sau hai kỷ nguyên (12,8 phút) tạo ra một đảm bảo kinh tế rất mạnh gọi là sự chắc chắn cuối cùng.

Trong vài năm qua, chúng tôi ngày càng trở nên khó chịu hơn với cách tiếp cận hiện tại. 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 vị trí và cơ chế cuối cùng theo từng kỷ nguyên, và (ii) 12,8 phút là quá dài và không ai quan tâm đến việc chờ đợi lâu như vậy.

Độ tin cậy khe đơn thay thế kiến trúc này bằng cơ chế giống hơn nhiều với Giai quyết đồng thuận Tendermint, trong đó khối N được hoàn thiện trước khi tạo khối N+1. Sự sai lệch chính so với Tendermint là chúng tôi giữ “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 validators ngừng hoạt động.”

Một biểu đồ về các đề xuất hàng đầuthiết kế độ tin cậy từng khe cắm_

Thách thức chính với SSF là dường như, nó ám chỉ rằng mỗi người đào Ethereum cần phải xuất bản hai tin nhắn mỗi 12 giây, điều này sẽ tạo ra một lượng công việc lớn mà chuỗi cần 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 mặc dù điều này cải thiện rõ rệt trải nghiệm người dùng bằng cách làm cho "tính chất cuối cùng" đến nhanh hơn, điều này không thay đổi việc 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ột lộ trình trung tâm 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 có thể sau đó đượ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 ở quy mô cao hơn nhiều.

Điều này tạo ra một phân chia các quyềntrong 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, duy trì và cải thiện một cấp độ cốt lõi cơ bản nhất định, và L2 có thể tập trung vào việc tiếp cận trực tiếp người dùng - thông qua các phương tiện khác nhau văn hóavà những sự cân nhắc về 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 sẽ nảy sinh: L2s 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ời nói, đã là trách nhiệm của các L2 để tạo ra các mạng "chuỗi phân cấp" của riêng họ. Một nhóm nhỏ các nhà xác minh sẽ ký duyệt các khối, có lẽ một lần mỗi vài trăm mili giây, và họ sẽ đặt "cọc" của mình vào những khối đó. Cuối cùng, các tiêu đề của các khối L2 này được công bố trên L1.

Bộ xác minh L2 có thể gian lận: họ có thể trước tiên ký kết khối B1, sau đó sau đó ký kết 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 đặt cọc của họ. Trong thực tế, chúng ta đã thấy các phiên bản tập trung của điều này, nhưng rollups đã chậm phát triển các mạng xếp hạng phi tập trung. Và bạn có thể bảo vệ rằng yêu cầu tất cả L2s đều thực hiện xếp hạng phi tập trung là một thỏa thuận không công bằng: chúng ta đang yêu cầu rollups cơ bản làm hầu hết công việc giống như việc tạo ra một L1 mới hoàn toàn. Vì lý do này và lý do khác, Justin Drake đã khuyến khích một cách để cung cấp tất cả L2s (cũng như L1) truy cập vào cơ chế tiền xác nhận trước toàn cầu của Ethereum chia sẻ:dựa trên sự xác nhận trước.

Xác nhận trước dựa trên

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

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

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

Meme "hình ảnh giống nhau" đang trở nên quá phổ biến ở thời điểm này, vì vậy tôi sẽ đưa một biểu đồ cũ tôi vẽ cách đây nhiều năm để mô tả kiến trúc slot và epoch của Gasper và một biểu đồ về xác nhận trước L2 cạnh nhau, và hy vọng rằng sẽ truyền đạt được ý kiến.

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

Một lý do đơn giản là số lượng nút. Trong khi cũ@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">decentralization / finality time / overhead tradeoff is looking milder now due to hyper-optimized BLS aggregation and in the near future ZK-STARKs, it’s still fundamentally true that:

1. “Thỏa thuận xấp xỉ” chỉ cần một vài nút trong khi tính chất kinh tế yêu cầu một phần lớn đáng kể của tất cả các nút.
2. Khi số lượng nút vượt quá một kích thướ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 hôm nay, một khe thời gian 12 giây được chia thành ba khe con, cho (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 người chứng thực ít hơn nhiều, chúng ta có thể giảm xuống còn hai khe con 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 chuyên nghiệp của các nút để thực hiện các thỏa thuận xấp xỉ (và vẫn sử dụng bộ kiểm chứng đầy đủ cho tính cuối cùng), chúng ta có thể giảm xuống khoảng ~2 giây.

Do đó, đối với tôi, (i) kiến trúc slot và 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 và epoch được tạo ra bằng nhau, và có giá trị trong việc khám phá một cách toàn diện hơn không gian thiết kế. Đặc biệt, đáng giá để khám phá các tùy chọn không được kết hợp 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ì?

Theo quan điểm của tôi, hiện tại có ba chiến lược hợp lý mà L2 có thể áp dụng:

1. Được “dựa” cả về mặt công nghệ lẫn tinh thần. Nghĩa là, họ tối ưu hóa để trở thành các đường ống 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ó (tính 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ể nghĩ về các rollups này như là các “mảnh vỡ được nhãn hiệu hóa”, nhưng chúng cũng có thể tham vọng hơn nhiều so với điều đó, và thậm chí thí nghiệm mạnh mẽ với 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 nó. Nếu bạn bắt đầu từ một máy chủ, sau đó thêm (i) chứng minh sự hợp lệ của STARK để đảm bảo rằng máy chủ đang tuân thủ các quy tắc, (ii) quyền đảm bảo cho người dùng để thoát hoặc buộc giao dịch, và có thể (iii) sự tự do lựa chọn tập thể, qua việc thoát hàng loạt được phối hợp hoặc thông qua khả năng bỏ phiếu để thay đổi người sắp xếp, thì bạn đã có đượ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 các hiệu quả của một máy chủ.
3. Cách tiếp cận compromise: một chuỗi nhanh với một trăm nút, với Ethereum cung cấp tính tương tác và an ninh bổ sung. Đây là lộ trình hiện tại thực tế của nhiều dự án L2.

Đối với một số ứng dụng, (ví dụ như ENS, keystores)], một thời gian khối 12 giây là đủ. Đối với những ứng dụng không phải là 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, các “kỷ nguyên” là SSF của Ethereum (có lẽ chúng ta có thể thay đổi việc đặt tên này để có nghĩa khác ngoài “slot đơn”, ví dụ, nó có thể là “Độ chắc chắn và tốc độ nhanh”). Nhưng các “khe” lại khác nhau trong mỗi trường hợp trên:

1. Một kiến trúc khe và kỷ nguyên gốc của Ethereum
2. Xác nhận trước máy chủ
3. Ủy ban xác nhận trước

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 biệt, nếu nó trở nên thực sự tốt, thì cảm giác như danh mục (3) không còn ý nghĩa nhiều. 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 dữ liệu ngoại chuỗi như plasmas và validiums. Nhưng nếu một kiến trúc Ethereum-native khe cắm-và-thời đại có thể giảm xuống cỡ “khe” 1 giây (tức là 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.

Hôm nay, chúng ta vẫn chưa 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 then chốt - mức độ phức tạp của những người đề xuất khối sẽ trở nên như thế nào - vẫn là một lĩnh vực có khá nhiều sự không chắc chắn. Các thiết kế như Orbit SSFlà rất gần đây, cho thấy rằng không gian thiết kế của các thiết kế slot và epoch nơi một cái gì đó giống như Orbit SSF là epoch vẫn chưa được khai thác đầy đủ. Chúng ta càng có nhiều lựa chọn, chúng ta càng có thể làm tốt hơn cho người dùng cả trên L1 và trên L2, và chúng ta càng có thể đơn giản hóa công việc của các nhà phát triển L2.

Tuyên bố:

1. Bài viết này được in lại từ [Vitalik].Chuyển tiếp Tiêu đề Gốc 'Epochs and slots all the way down: cách để cung cấp thời gian xác nhận giao dịch nhanh hơn cho người dùng Ethereum'. 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 bản này, vui lòng liên hệ Cổng Họcđội ngũ và họ sẽ xử lý ngay lập tức.
2. Miễn trừ trách nhiệm: 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 đại diện cho 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ó nêu rõ, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.