Tiêu đề gốc: Tương lai có thể có của giao thức Ethereum, phần 2: The Surge
Tác giả: Vitalik, người sáng lập Ethereum, biên soạn: Deng Tong, Jinse Finance
Đặc biệt cảm ơn Justin Drake, Francesco, Hsiao-wei Wang, @antanttc và Georgios Konstantopoulos
Ngay từ đầu, đã có hai chiến lược mở rộng trong lộ trình của Ethereum . Một trong đó là "sharding" : thay vì xác thực và lưu trữ tất cả giao dịch trong Chuỗi , mỗi nút chỉ cần xác thực và lưu trữ một tập hợp con giao dịch nhỏ. Đây cũng là cách hoạt động của bất kỳ mạng ngang hàng nào khác (chẳng hạn như BitTorrent), vì vậy chúng tôi chắc chắn có thể làm cho blockchain hoạt động theo cách tương tự. Giao thức còn lại là giao thức lớp 2: mạng sẽ nằm trên Ethereum, cho phép chúng được hưởng lợi hoàn toàn từ tính bảo mật của nó trong khi giữ hầu hết dữ liệu và tính toán cách xa Chuỗi chính. "Giao thức lớp 2" đề cập đến các kênh trạng thái vào năm 2015, Plasma vào năm 2017 và Rollups vào năm 2019. Rollups mạnh hơn các kênh trạng thái hoặc Plasma, nhưng chúng yêu cầu lượng lớn băng thông dữ liệu trên Chuỗi . May mắn thay, đến năm 2019, nghiên cứu sharding đã giải quyết được vấn đề xác minh “tính sẵn có dữ liệu ” trên quy mô lớn. Kết quả là, hai con đường đã hợp nhất và chúng tôi có được lộ trình tập trung vào tổng hợp, đây vẫn là chiến lược mở rộng của Ethereum ngày nay.
The Surge, Phiên bản lộ trình năm 2023.
Lộ trình tập trung vào tổng hợp đề xuất một sự phân công lao động đơn giản: Ethereum L1 tập trung vào việc trở thành lớp cơ sở mạnh mẽ và phi tập trung , trong khi L2 có nhiệm vụ giúp mở rộng mở rộng hệ sinh thái. Đây là một mô hình lặp đi lặp lại trong toàn xã hội: hệ thống tòa án (L1) không phải ở đó để siêu nhanh và hiệu quả mà để bảo vệ các hợp đồng và quyền tài sản, và các doanh nhân (L2) cần xây dựng một lớp nền tảng vững chắc bên trên nó và thực hiện nhân loại đến (ẩn dụ và nghĩa đen) sao Hỏa.
Năm nay, lộ trình tập trung vào tổng hợp đã đạt được những thành công quan trọng: Băng thông dữ liệu Ethereum L1 đã tăng đáng kể với blob EIP-4844 và nhiều đợt tổng hợp EVM hiện đang ở giai đoạn đầu tiên. Việc triển khai sharding rất không đồng nhất và đa dạng, trong đó mỗi L2 hoạt động như một "phân đoạn" với các quy tắc và logic nội bộ riêng hiện đã trở thành hiện thực. Nhưng như chúng ta đã thấy, việc đi theo con đường này có một số thách thức riêng. Vì vậy , bây giờ chúng tôi được nhiệm vụ hoàn thành lộ trình lấy Rollup làm trung tâm và giải quyết những vấn đề này trong khi vẫn duy trì tính mạnh mẽ và phi tập trung khiến Ethereum L1 trở nên độc đáo.
Tăng đột biến: Mục tiêu chính
Hơn 100.000 TPS trên L1+L2
Giữ L1 phi tập trung và mạnh mẽ
Ít nhất một số L2 kế thừa đầy đủ các đặc tính cốt lõi của Ethereum(không cần tin cậy, mở, chống kiểm duyệt)
Khả năng tương tác tối đa giữa L2. Ethereum sẽ giống như một hệ sinh thái chứ không phải 34 blockchain khác nhau.
Bộ ba bất khả thi mở rộng
Bộ ba mở rộng là một ý tưởng được đề xuất vào năm 2017 cho rằng có sự căng thẳng giữa ba thuộc tính của blockchain: phi tập trung(cụ thể hơn: chi phí chạy nút thấp), mở rộng(cụ thể hơn: chi phí chạy nút thấp) Cụ thể: xử lý lượng lớn các nút chạy. số lượng giao dịch) và bảo mật (cụ thể hơn: kẻ tấn công sẽ cần phải xâm phạm phần lớn nút trong toàn bộ mạng để một giao dịch không thành công).
Điều đáng chú ý là bộ ba bất khả thi không phải là một định lý và bài viết giới thiệu bộ ba bất khả thi không đi kèm với chứng minh toán học. Nó đưa ra một lập luận toán học theo kinh nghiệm: nếu một nút thân thiện phi tập trung (ví dụ: máy tính xách tay tiêu dùng) có thể xác minh N giao dịch mỗi giây và bạn có một Chuỗi xử lý k*N giao dịch mỗi giây, thì (i) mỗi giao dịch sẽ chỉ được nhìn thấy bằng 1/k nút, nghĩa là kẻ tấn công chỉ cần thỏa hiệp một vài nút để đẩy các giao dịch xấu hoặc (ii) nút của bạn sẽ trở nên mạnh mẽ và Chuỗi của bạn không phi tập trung. Mục đích của bài viết này không bao giờ là để chứng tỏ rằng việc phá vỡ bộ ba bất khả thi là không thể; mà nó chỉ để chứng tỏ rằng việc phá vỡ bộ ba bất khả thi là rất khó - nó đòi hỏi phải suy nghĩ theo cách nào đó mà lập luận đó ngụ ý.
Trong những năm qua, một số Chuỗi hiệu suất cao thường tuyên bố rằng họ đã giải quyết được bộ ba bất khả thi mà không thực hiện bất kỳ biện pháp khéo léo ở cấp cơ sở hạ tầng, thường là bằng cách sử dụng các thủ thuật công nghệ phần mềm để tối ưu hóa nút . Điều này luôn gây hiểu lầm và việc chạy nút trong Chuỗi như vậy sẽ luôn khó khăn hơn nhiều so với Ethereum. Bài đăng này khám phá nhiều điểm tinh tế về lý do tại sao lại như vậy (và tại sao chỉ riêng kỹ thuật phần mềm máy trạm L1 không thể tự mở rộng Ethereum).
Tuy nhiên, sự kết hợp giữa lấy mẫu tính khả dụng dữ liệu và SNARK sẽ giải quyết được bộ ba bất khả thi: nó cho phép máy trạm xác minh rằng một lượng dữ liệu nhất định có sẵn và một số bước tính toán nhất định đã được thực hiện chính xác, trong khi chỉ tải xuống một phần nhỏ dữ liệu đó và chạy Khối lượng tính toán nhỏ hơn nhiều. SNARK không đáng tin cậy. Lấy mẫu tính khả dụng của dữ liệu có mô hình tin cậy N thiểu số tinh tế, nhưng nó vẫn giữ được đặc tính cơ bản của Chuỗi không thể mở rộng mà ngay cả một cuộc tấn công 51% cũng không thể buộc mạng chấp nhận các khối xấu.
Một phương pháp khác cho bộ ba bất khả thi là kiến trúc Plasma, sử dụng các kỹ thuật khéo léo để đẩy trách nhiệm giám sát tính sẵn có dữ liệu cho người dùng theo cách tương thích khích lệ . Trở lại năm 2017-2019, khi tất cả những gì chúng ta cần để mở rộng điện toán là bằng chứng gian lận, khả năng bảo mật của Plasma rất hạn chế, nhưng việc phổ biến SNARK đã khiến kiến trúc Plasma phù hợp hơn với nhiều trường hợp sử dụng hơn trước.
Những tiến bộ hơn nữa trong việc lấy mẫu tính sẵn có dữ liệu
Chúng ta đang cố gắng giải quyết vấn đề gì?
Tính đến ngày 13 tháng 3 năm 2024, khi nâng cấp Dencun ra mắt , blockchain Ethereum có ba "đốm màu" khoảng 125 kB mỗi khoảng thời gian 12 giây hoặc khoảng 375 kB băng dữ liệu có sẵn mỗi khoảng thời gian. Giả sử rằng dữ liệu giao dịch được xuất bản trực tiếp lên Chuỗi , quá trình truyền ERC20 xấp xỉ 180 byte, do đó TPS tối đa của rollups trên Ethereum là:
375000/12/180 = 173,6 TPS
Nếu chúng ta thêm calldata của Ethereum(tối đa theo lý thuyết: 30 triệu Gas mỗi khe / 16 Gas mỗi byte = 1.875.000 byte mỗi khe), thì con số này sẽ trở thành 607 TPS. Đối với PeerDAS, kế hoạch là tăng mục tiêu số lượng blob lên 8-16, điều này sẽ cung cấp cho chúng tôi dữ liệu cuộc gọi là 463-926 TPS.
Đây là một cải tiến đáng kể so với Ethereum L1, nhưng vẫn chưa đủ. Chúng tôi muốn có nhiều mở rộng hơn. Mục tiêu trung hạn của chúng tôi là 16 MB mỗi khe cắm, khi kết hợp với những cải tiến về nén dữ liệu tổng hợp sẽ mang lại cho chúng tôi khoảng 58.000 TPS.
Nó là gì và nó hoạt động như thế nào?
PeerDAS là một cách triển khai "lấy mẫu một chiều" tương đối đơn giản. Mỗi đốm màu trong Ethereum là một đa thức lần 4096 trên trường số nguyên tố 253 bit. Chúng tôi phát sóng "thị phần" của đa thức, trong đó mỗi thị phần bao gồm 16 đánh giá tại 16 tọa độ liền kề được lấy từ tổng số 8192 bộ tọa độ. Có thể phục hồi đốm màu trong 4096 trên lần đánh giá lần(sử dụng các tham số hiện được đề xuất: 64 trong số 128 mẫu có thể có).
PeerDAS hoạt động bằng cách yêu cầu mỗi máy trạm lắng nghe một số lượng nhỏ mạng con, trong đó mạng con thứ i phát mẫu thứ i của bất kỳ blob nào và yêu cầu thêm những gì cần thiết trên các mạng con khác bằng cách hỏi các đồng nghiệp trong mạng p2p toàn cầu Blob (ai sẽ nghe trên các mạng con khác nhau). Phiên bản bảo thủ hơn, SubnetDAS, chỉ sử dụng cơ chế mạng con và không có lớp ngang hàng yêu cầu bổ sung. Khuyến nghị hiện tại là nút tham gia Bằng chứng cổ phần sử dụng SubnetDAS và nút khác (tức là "máy trạm") sử dụng PeerDAS.
Về lý thuyết, chúng tôi có thể mở rộng lấy mẫu 1D khá xa: nếu chúng tôi tăng số lượng blob tối đa lên 256 (vì vậy mục tiêu là 128), thì chúng tôi sẽ đạt được mục tiêu 16 MB, trong khi việc lấy mẫu dữ liệu sẵn có chỉ tốn 16 cho mỗi mẫu nút* 128 đốm màu * 512 byte mỗi mẫu trên mỗi blob = 1 MB băng thông dữ liệu trên mỗi khe. Điều này chỉ nằm trong phạm vi cho phép của chúng tôi: có thể thực hiện được nhưng điều đó có nghĩa là máy trạm bị hạn chế về băng thông không thể lấy mẫu. Chúng ta có thể tối ưu hóa điều này bằng cách giảm số lượng đốm màu và tăng kích thước đốm màu, nhưng điều này sẽ khiến việc xây dựng lại tốn kém hơn.
Vì vậy, cuối cùng, chúng tôi muốn tiến thêm một bước nữa và thực hiện lấy mẫu 2D, bằng cách lấy mẫu ngẫu nhiên không chỉ trong các đốm màu mà còn giữa các đốm màu. Thuộc tính tuyến tính của các cam kết KZG được sử dụng để "mở rộng" tập hợp các đốm màu trong một khối với danh sách các "đốm màu ảo" mới mã hóa dư thừa cùng một thông tin.
Lấy mẫu 2D Nguồn: a16z.
Điều quan trọng là không cần có đốm màu nào để tính toán mở rộng của các cam kết, do đó, về cơ bản, chương trình này thân thiện với việc xây dựng khối phân tán. Nút thực sự xây dựng khối chỉ cần có cam kết Blob KZG và có thể dựa vào chính DAS để xác minh tính khả dụng của Blob. 1D DAS vốn đã thân thiện với việc xây dựng khối phân tán.
Các kết nối với nghiên cứu hiện tại là gì?
Bài viết gốc về tính sẵn có dữ liệu(2018): https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
Bài viết tiếp theo: https://arxiv.org/abs/1809.09044
Bài đăng giải thích về DAS, Paradigm: https://www.paradigm.xyz/2022/08/das
KZG cam kết có sẵn 2D: https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081
PeerDAS trên ethresear.ch: https://ethresear.ch/t/peerdas-a-simpler-das-approach-USE-battle-tested-p2p-comComponents/16541 và giấy: https://eprint.iacr.org / 2024/1362
EIP-7594: https://eips.ethereum.org/EIPS/eip-7594
SubnetDAS trên ethresear.ch: https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169
Các sắc thái của việc phục hồi dữ liệu trong lấy mẫu 2D: https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256
Cần phải làm gì nữa, cần phải đánh đổi những gì?
Bước tiếp theo là hoàn tất việc triển khai và triển khai PeerDAS. Kể từ đó, chúng tôi đã nỗ lực gia tăng để liên tục tăng số lượng blob trên PeerDAS, đồng thời quan sát cẩn thận mạng và cải tiến phần mềm để đảm bảo tính bảo mật. Trong thời gian chờ đợi, chúng tôi hy vọng sẽ tiến hành nhiều công việc học thuật hơn về PeerDAS và các phiên bản chính thức hóa DAS khác cũng như sự tương tác của chúng với các vấn đề như bảo mật quy tắc fork.
Trong tương lai, chúng tôi cần phải nỗ lực nhiều hơn để tìm ra phiên bản lý tưởng của 2D DAS và chứng minh các đặc tính bảo mật của nó. Chúng tôi cũng hy vọng cuối cùng sẽ chuyển từ KZG sang các giải pháp thay thế kháng lượng tử không yêu cầu thiết lập đáng tin cậy. Hiện tại, chúng tôi không biết có ứng viên nào thân thiện với việc xây dựng khối phân tán. Ngay cả kỹ thuật "vũ phu" đắt tiền sử dụng STARK đệ quy để tạo bằng chứng hợp lệ cho việc xây dựng lại các hàng và cột cũng không đủ vì về mặt kỹ thuật, kích thước băm của STARK là O(log(n) * log(log(n)) (với STIR ), trên thực tế, STARK gần như lớn bằng toàn bộ đốm màu.
Về lâu dài, tôi cho rằng con đường thực tế là:
Công cụ DAS 2D lý tưởng;
Gắn bó với 1D DAS, hy sinh hiệu suất băng thông lấy mẫu và chấp nhận giới hạn dữ liệu thấp hơn để đơn giản và mạnh mẽ;
(Trục cứng) Loại bỏ DA và sử dụng hoàn toàn Plasma làm kiến trúc lớp 2 chính mà chúng tôi tập trung vào.
Chúng ta có thể ứng xử những điều này bằng cách cân nhắc phạm vi:
Lưu ý rằng tùy chọn này vẫn tồn tại ngay cả khi chúng tôi quyết định mở rộng thực thi trực tiếp trên L1. Điều này là do nếu L1 xử lý lượng lớn TPS, các khối L1 sẽ trở nên rất lớn và khách hàng sẽ cần một phương pháp hiệu quả để xác minh rằng chúng đúng, vì vậy chúng tôi phải sử dụng cùng một công nghệ hỗ trợ cuộn lên (ZK- EVM và DAS) với L1 .
Nó tương tác với các phần khác của lộ trình như thế nào?
Nhu cầu về 2D DAS sẽ giảm đi hoặc ít nhất là bị trì hoãn nếu việc nén dữ liệu được thực hiện (xem bên dưới) và sẽ giảm hơn nữa nếu Plasma được sử dụng rộng rãi. DAS cũng đặt ra những thách thức đối với các giao thức và cơ chế xây dựng khối phân tán: mặc dù về mặt lý thuyết, DAS thân thiện với việc tái cấu trúc phân tán, nhưng trên thực tế, nó cần được kết hợp với Đề án danh sách đưa vào và cơ chế lựa chọn fork xung quanh nó.
nén dữ liệu
Chúng ta đang cố gắng giải quyết vấn đề gì?
Mỗi giao dịch trong Rollup chiếm lượng lớn không gian dữ liệu trên Chuỗi : chuyển ERC20 yêu cầu khoảng 180 byte. Ngay cả với việc lấy mẫu tính khả dụng dữ liệu lý tưởng, điều này cũng hạn chế mở rộng của các giao thức Lớp 2. Với 16 MB mỗi khe, chúng tôi nhận được:
16000000/12/180 = 7407 TPS
Điều gì sẽ xảy ra nếu, ngoài việc giải tử số, chúng ta còn có thể giải mẫu số và làm cho mỗi giao dịch trong danh sách chiếm ít byte hơn Chuỗi?
Nó là gì và nó hoạt động như thế nào?
Tôi cho rằng lời giải thích hợp lý nhất là bức ảnh này từ hai năm trước:
Mức tăng đơn giản nhất là nén 0 byte: thay thế mỗi chuỗi dài các byte 0 bằng hai byte biểu thị số byte 0. Tiến thêm một bước nữa, chúng tôi khai thác các thuộc tính dành riêng cho giao dịch:
Tập hợp chữ ký - Chúng tôi chuyển từ chữ ký ECDSA sang chữ ký BLS, có đặc tính kết hợp nhiều chữ ký lại với nhau thành một chữ ký duy nhất có thể chứng minh tính hợp lệ của tất cả các chữ ký gốc. L1 không tính đến điều này vì chi phí tính toán để xác minh (ngay cả khi tổng hợp) cao hơn, nhưng trong hoàn cảnh khan hiếm dữ liệu như L2, chúng được cho là có ý nghĩa. Chức năng tổng hợp của ERC-4337 cung cấp một cách để đạt được điều này.
Thay thế địa chỉ bằng con trỏ - Nếu địa chỉ đã được sử dụng trước đó, chúng ta có thể thay thế địa chỉ 20 byte bằng con trỏ 4 byte trỏ đến vị trí lịch sử. Điều này là cần thiết để đạt được lợi nhuận tối đa, mặc dù sẽ trả giá nỗ lực để đạt được vì nó đòi hỏi (ít nhất là một phần) lịch sử của blockchain để trở thành một phần của quốc gia một cách hiệu quả.
Tuần tự hóa tùy chỉnh các giá trị giao dịch - Hầu hết các giá trị giao dịch chỉ có rất ít số, vd. 0,25 ETH được đại diện bởi 250.000.000.000.000.000 wei. Gas cơ bản tối đa và phí ưu tiên hoạt động tương tự. Do đó, chúng ta có thể biểu diễn hầu hết các giá trị tiền tệ một cách rất gọn bằng cách sử dụng định dạng dấu phẩy động thập phân tùy chỉnh hoặc thậm chí từ điển các giá trị đặc biệt phổ biến.
Các kết nối với nghiên cứu hiện tại là gì?
Khám phá từ Sequence.xyz: https://sequence.xyz/blog/compressing-calldata
Hợp đồng tối ưu hóa dữ liệu cuộc gọi cho L2, từ ScopeLift: https://github.com/ScopeLift/l2-optimizooooors
Một chiến lược khác - Các bản tổng hợp dựa trên bằng chứng xác thực (còn gọi là các bản tổng hợp ZK) công bố sự khác biệt về trạng thái thay vì các giao dịch: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce- the-l2- dữ liệu-footprint-on-l1/9975
Ví BLS - Tổng hợp BLS qua ERC-4337: https://github.com/getwax/bls-wallet
Cần phải làm gì nữa, cần phải đánh đổi những gì?
Công việc chính còn lại phải làm là thực hiện kế hoạch trên. Sự đánh đổi chính là:
Việc chuyển sang chữ ký BLS trả giá nỗ lực đáng kể và giảm khả năng tương thích với các chip phần cứng đáng tin cậy nhằm cải thiện tính bảo mật. Thay vào đó, có thể sử dụng trình bao bọc ZK-SNARK cho các sơ đồ chữ ký khác.
Nén động (chẳng hạn như thay thế địa chỉ bằng con trỏ) làm phức tạp mã máy trạm.
Việc xuất bản các khác biệt trạng thái lên Chuỗi thay vì giao dịch sẽ làm giảm kiểm toán và ngăn nhiều phần mềm (chẳng hạn như Block Explorer) hoạt động.
Nó tương tác với các phần khác của lộ trình như thế nào?
Việc áp dụng ERC-4337 và sự kết hợp cuối cùng của các bộ phận của nó vào L2 EVM có thể đẩy nhanh đáng kể việc triển khai các công nghệ hội tụ. Việc kết hợp các bộ phận của ERC-4337 vào L1 có thể đẩy nhanh quá trình triển khai trên L2.
Huyết tương tổng quát
Chúng ta đang cố gắng giải quyết vấn đề gì?
Ngay cả với các đốm màu 16 MB và nén dữ liệu, 58.000 TPS không nhất thiết đủ để đảm nhận hoàn toàn các khoản thanh toán của người tiêu dùng, mạng xã hội phi tập trung hoặc các lĩnh vực băng thông cao khác, đặc biệt nếu chúng ta bắt đầu nghĩ đến quyền riêng tư, điều này có thể khiến mở rộng giảm 3-8 lần. Đối với các ứng dụng có khối lượng lớn, giá trị thấp, một lựa chọn hiện nay là Validium, giúp giữ dữ liệu ngoài Chuỗi và có mô hình bảo mật thú vị trong đó các nhà khai thác không thể lấy cắp tiền của người dùng nhưng chúng có thể biến mất và đóng băng tất cả tiền của Người dùng tạm thời hoặc vĩnh viễn. Nhưng chúng ta có thể làm tốt hơn.
Nó là gì và nó hoạt động như thế nào?
Plasma là một giải pháp mở rộng bao gồm việc các nhà khai thác xuất bản các khối ngoài Chuỗi và đặt gốc Merkle của các khối đó trên Chuỗi(không giống như rollups , rollups toàn bộ khối trên Chuỗi). Đối với mỗi khối, nhà điều hành sẽ gửi cho mỗi người dùng một nhánh Merkle để chứng minh điều gì đã xảy ra hoặc không xảy ra với tài sản của người dùng đó. Người dùng có thể rút tài sản bằng cách cung cấp Merkle fork. Điều quan trọng là chi nhánh không cần phải root ở trạng thái mới nhất - vì vậy ngay cả khi dữ liệu không có sẵn, người dùng vẫn có thể khôi phục tài sản của mình bằng cách lấy lại trạng thái mới nhất hiện có. Nếu người dùng cam kết một nhánh không hợp lệ (ví dụ: rút tài sản mà họ đã gửi cho người khác hoặc chính nhà điều hành tạo ra tài sản một cách bất ngờ), cơ chế thách thức Chuỗi có thể xét xử chính xác tài sản đó thuộc về ai.
Sơ Chuỗi chuỗi tiền mặt Plasma. Giao dịch tiêu tiền i được đặt ở vị trí thứ i trong cây. Trong ví dụ này, giả sử tất cả các cây trước đó đều hợp lệ, chúng ta biết rằng Eve hiện sở hữu đồng xu 1, David sở hữu đồng xu 4 và George sở hữu đồng xu 6.
Các phiên bản đầu tiên của Plasma chỉ có thể xử lý các trường hợp sử dụng thanh toán và không thể được quảng bá một cách hiệu quả hơn nữa. Tuy nhiên, Plasma sẽ trở nên mạnh mẽ hơn nếu chúng ta yêu cầu mọi root phải được xác minh bằng SNARK. Mỗi trò chơi thử thách có thể được đơn giản hóa rất nhiều vì chúng tôi loại bỏ hầu hết các con đường có thể khiến người chơi gian lận. Những con đường mới cũng đã được mở ra, cho phép công nghệ Plasma mở mở rộng sang nhiều loại tài sản hơn. Cuối cùng, miễn là nhà điều hành không gian lận, người dùng có thể rút tiền ngay lập tức mà không cần chờ thời gian thử thách một tuần.
Một phương pháp(không phải phương pháp duy nhất) tạo ra Chuỗi EVM Plasma: sử dụng ZK-SNARK để xây dựng các cây UTXO song song phản ánh những thay đổi số dư do EVM thực hiện và xác định đâu là ánh xạ duy nhất của "cùng một loại tiền tệ" tới các điểm khác nhau trong lịch sử. Cấu trúc plasma sau đó có thể được xây dựng trên cơ sở này.
Một nhận xét quan trọng là hệ thống Plasma không cần phải hoàn hảo. Ngay cả khi bạn chỉ có thể bảo vệ một phần tài sản(ví dụ: thậm chí chỉ token chưa được di chuyển trong tuần qua), thì bạn đã cải thiện đáng kể trạng thái hiện tại của EVM mở rộng cao và đó là sự xác thực.
Một loại cấu trúc khác là cấu trúc lai Plasma/ rollups, chẳng hạn như Intmax. Các cấu trúc này đặt một lượng dữ liệu rất nhỏ cho mỗi người dùng trên Chuỗi(ví dụ: 5 byte) và bằng cách đó, bạn có thể nhận được các thuộc tính giữa Plasma và Aggregation: trong trường hợp Intmax, bạn có thể có được Mở rộng và quyền riêng tư ở mức rất cao, ngay cả trong thế giới 16 MB, giới hạn dung lượng lý thuyết là khoảng 16.000.000 / 12 / 5 = 266.667 TPS.
Các kết nối với nghiên cứu hiện tại là gì?
Giấy Plasma gốc: https://plasma.io/plasma-deprecated.pdf
Tiền mặt Plasma: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
Dòng tiền plasma: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#-Exit
Intmax (2023): https://eprint.iacr.org/2023/1082
Cần phải làm gì nữa, cần phải đánh đổi những gì?
Nhiệm vụ chính còn lại là đưa hệ thống Plasma vào sản xuất. Như đã đề cập ở trên, "plasma so với validium" không phải là sự đối lập nhị phân: bất kỳ validium nào cũng có thể cải thiện hiệu suất bảo mật ít nhất một chút bằng cách thêm chức năng Plasma vào cơ chế thoát. Nghiên cứu này một phần nhằm đạt được các đặc tính tốt nhất của EVM (về yêu cầu tin cậy, chi phí Gas L1 trong trường hợp xấu nhất và lỗ hổng DoS) cũng như các cấu trúc thay thế dành riêng cho ứng dụng. Ngoài ra, Plasma có độ phức tạp về mặt khái niệm cao hơn rollups , vấn đề này cần được giải quyết trực tiếp thông qua nghiên cứu và xây dựng một khuôn khổ chung tốt hơn.
Nhược điểm chính của việc sử dụng thiết kế Plasma là chúng phụ thuộc nhiều hơn vào người vận hành và khó "xây dựng" hơn, mặc dù các thiết kế Plasma/rollup lai thường tránh được điểm yếu này.
Nó tương tác với các phần khác của lộ trình như thế nào?
Giải pháp Plasma càng hiệu quả thì áp lực lên L1 càng ít để có được khả năng sẵn sàng dữ liệu hiệu suất cao. Việc chuyển các hoạt động sang L2 cũng làm giảm áp lực MEV lên L1.
Hệ thống chứng minh L2 trưởng thành
Chúng ta đang cố gắng giải quyết vấn đề gì?
Ngày nay, hầu hết các tập hợp chưa thực sự không đáng tin cậy; có một hội đồng bảo mật có khả năng ghi đè các bằng chứng (lạc quan hoặc hợp lệ) về hành vi của hệ thống. Trong một số trường hợp, hệ thống chứng thực thậm chí không tồn tại hoặc nếu có thì nó chỉ có chức năng "tư vấn". Những cái hàng đầu là (i) một số bản tổng hợp dành riêng cho ứng dụng, chẳng hạn như Nhiên liệu, không đáng tin cậy và (ii) tính đến văn bản này, Optimism và Arbitrum, hai bản tổng hợp EVM hoàn chỉnh đã triển khai tính không tin cậy một phần. Cột mốc quan trọng này được gọi là "Giai đoạn 1 ." Lý do Rollups không được phát triển thêm là do lo ngại về lỗi trong mã. Chúng tôi cần sự tổng hợp không cần tin cậy, vì vậy chúng tôi cần giải quyết vấn đề này ngay từ đầu.
Nó là gì và nó hoạt động như thế nào?
Đầu tiên chúng ta cùng xem lại hệ thống “sân khấu” được giới thiệu ở đầu bài viết này. Có những yêu cầu chi tiết hơn nhưng tóm tắt như sau:
Giai đoạn 0: Người dùng phải có khả năng chạy nút và đồng bộ hóa Chuỗi. Sẽ ổn thôi nếu việc xác minh hoàn toàn được tin cậy/tập trung.
Giai đoạn 1: Phải có hệ thống bằng chứng (không cần sự tin cậy) để đảm bảo rằng chỉ những giao dịch hợp lệ mới được chấp nhận. Cho phép một ủy ban an toàn có thể ghi đè hệ thống chứng thực nhưng chỉ với ngưỡng biểu quyết 75%. Ngoài ra, phần chặn số đại biểu của Hội đồng (tức là trên 26%) phải nằm ngoài các công ty chính xây dựng tập hợp. Cho phép các cơ chế nâng cấp ít mạnh mẽ hơn (chẳng hạn như DAO), nhưng phải có độ trễ đủ dài để nếu nâng cấp độc hại được chấp thuận, người dùng có thể rút tiền trước khi nâng cấp ra mắt.
Giai đoạn 2: Phải có hệ thống bằng chứng (không cần sự tin cậy) để đảm bảo rằng chỉ những giao dịch hợp lệ mới được chấp nhận. Ví dụ, Hội đồng Bảo an chỉ được phép can thiệp nếu có những sai sót rõ ràng trong mã. Nếu hai hệ thống chứng minh dư thừa không nhất quán với nhau hoặc nếu một hệ thống chứng minh chấp nhận hai nghiệm chứng sau trạng thái khác nhau cho cùng một khối (hoặc không chấp nhận bất cứ điều gì trong một khoảng thời gian đủ dài, chẳng hạn như một tuần). Cơ chế nâng cấp được cho phép, nhưng chỉ với độ trễ dài.
Mục tiêu của chúng tôi là đạt đến giai đoạn thứ hai. Thử thách chính khi đạt đến giai đoạn thứ hai là có đủ tự tin để chứng minh rằng hệ thống trên thực tế đủ tin cậy. Có hai phương pháp chính để làm điều này:
Xác minh chính thức: Chúng ta có thể sử dụng các kỹ thuật tính toán và toán học hiện đại để chứng minh (một cách lạc quan hoặc hiệu quả) rằng hệ thống chỉ chấp nhận các khối vượt qua đặc tả EVM. Những kỹ thuật này đã tồn tại trong nhiều thập kỷ, nhưng những tiến bộ gần đây (chẳng hạn như Lean 4) đã khiến chúng trở nên thiết thực hơn và những tiến bộ trong việc kiểm chứng được hỗ trợ bởi AI có thể đẩy nhanh hơn nữa xu hướng này.
Multi-Proofers: Tạo ra các hệ thống đa bằng chứng và bỏ tiền vào 2/3 (hoặc lớn hơn) multisig giữa các hệ thống bằng chứng này và ủy ban bảo mật (và/hoặc các tiện ích khác có giả định về độ tin cậy, chẳng hạn như TEE). Nếu hệ thống được chứng minh là đồng ý thì Hội đồng không có quyền lực. Nếu họ không đồng ý, Hội đồng chỉ được chọn một trong đó và không thể đơn phương áp đặt câu trả lời của mình.
Biểu đồ cách điệu của nhiều người chứng minh, kết hợp hệ thống chứng minh lạc quan, hệ thống chứng minh tính hợp lệ và ủy ban an toàn.
Các kết nối với nghiên cứu hiện tại là gì?
EVM K Semantics (công việc xác minh chính thức từ năm 2017): https://github.com/runtimeverification/evm-semantics
Trình diễn ý tưởng nhiều người tục ngữ (2022): https://www.youtube.com/watch?v=6hfVzCWT6YI
Taiko có kế hoạch sử dụng nhiều bằng chứng: https://docs.taiko.xyz/core-concepts/multi-proofs/
Cần phải làm gì nữa, cần phải đánh đổi những gì?
Để xác minh chính thức, có rất nhiều. Chúng tôi cần tạo một phiên bản được xác minh chính thức của toàn bộ bộ chứng minh SNARK của EVM. Đây là một dự án cực kỳ phức tạp, mặc dù chúng tôi đã bắt đầu thực hiện nó. Có một thủ thuật giúp đơn giản hóa đáng kể nhiệm vụ: chẳng hạn, chúng ta có thể tạo ra một bộ chứng minh SNARK được xác minh chính thức cho một máy ảo tối thiểu. RISC-V hoặc Cairo, sau đó viết bản triển khai EVM trong VM tối thiểu đó (và chính thức chứng minh tính tương đương của nó với một số thông số kỹ thuật EVM khác).
Có hai phần chính còn lại cho nhiều người chuẩn bị. Trước tiên, chúng ta cần có đủ niềm tin vào ít nhất hai hệ thống chứng minh khác nhau, rằng mỗi hệ thống trong số đó đều an toàn hợp lý và nếu chúng gặp sự cố, chúng sẽ gặp sự cố vì những lý do khác nhau và không liên quan (để chúng không gặp sự cố cùng một lúc) . Thứ hai, chúng ta cần mức độ đảm bảo rất cao về logic cơ bản của hệ thống chứng minh hợp nhất. Đây là một đoạn mã nhỏ. Có phương pháp để làm cho nó trở nên rất nhỏ - chỉ cần lưu trữ tiền trong một hợp đồng nhiều chữ ký an toàn mà người ký là hợp đồng đại diện cho hệ thống chứng thực cá nhân - nhưng điều này trả giá trả giá bằng chi phí gas trên Chuỗi cao. Cần phải tìm thấy sự cân bằng giữa hiệu quả và bảo mật.
Nó tương tác với các phần khác của lộ trình như thế nào?
Chuyển các hoạt động sang L2 làm giảm áp lực MEV lên L1.
Cải thiện khả năng tương tác chéo L2
Chúng ta đang cố gắng giải quyết vấn đề gì?
Một trong những thách thức với hệ sinh thái L2 ngày nay là người dùng khó điều hướng. Ngoài ra, phương pháp đơn giản nhất thường đưa ra các giả định về độ tin cậy: cầu nối tập trung, máy trạm RPC, v.v. Nếu chúng ta nghiêm túc với ý tưởng rằng L2 là một phần của Ethereum, thì chúng ta cần làm cho việc sử dụng hệ sinh thái L2 giống như sử dụng hệ sinh thái Ethereum thống nhất.
Một ví dụ tồi tệ (thậm chí nguy hiểm: Cá nhân tôi đã mất 100 đô la do chọn sai Chuỗi ở đây) ví dụ về UX chéo L2 - mặc dù đây không phải lỗi của Polymarket, nhưng khả năng tương tác giữa L2 phải là Cộng đồng Trách nhiệm (ERC) tiêu chuẩn Ethereum. Trong hệ sinh thái Ethereum hoạt động tốt, việc gửi token từ L1 đến L2 hoặc từ L2 này sang L2 khác sẽ giống như gửi token trong cùng một L1.
Nó là gì và nó hoạt động như thế nào?
Có nhiều loại cải tiến khả năng tương tác chéo L2. Nói chung, phương pháp đặt những câu hỏi này là lưu ý rằng về mặt lý thuyết, Ethereum tập trung vào tổng hợp cũng giống như L1 thực hiện sharding, sau đó hỏi xem phiên bản L2 hiện tại Ethereum không đạt được mức lý tưởng trong thực tế như thế nào. Dưới đây là một số:
Địa chỉ cụ thể Chuỗi: Chuỗi(L1, Optimism, Arbitrum...) phải là một phần của địa chỉ. Sau khi được triển khai, quy trình gửi qua L2 có thể đạt được chỉ bằng cách nhập địa chỉ vào trường "gửi", tại thời điểm đó, ví có thể tìm ra cách gửi trong nền (bao gồm cả việc sử dụng giao thức bắc cầu).
Yêu cầu thanh toán cụ thể theo Chuỗi: Tạo ra thông báo có dạng “Gửi cho tôi token X thuộc loại Y trên Chuỗi Z” phải đơn giản và được chuẩn hóa. Có hai trường hợp sử dụng chính cho việc này: (i) thanh toán, cho dù là dịch vụ giữa người với người hay giữa người với người bán, và (ii) ví dụ: dapp yêu cầu tiền. Ví dụ về Polymarket ở trên.
Trao đổi Chuỗi và thanh toán gas : Cần có một giao thức mở được tiêu chuẩn hóa để thể hiện các hoạt động xuyên Chuỗi, chẳng hạn như "Tôi gửi 1 ETH theo Optimism cho người đã gửi 0,9999 ETH trên Arbitrum " và "Tôi gửi 0,0001 ETH theo Optimism " Bất kỳ ai bao gồm giao dịch này trên Arbitrum ". ERC-7683 đều là một nỗ lực ở trường hợp trước và RIP-7755 là một nỗ lực ở trường hợp sau, mặc dù cả hai đều chung chung hơn các trường hợp sử dụng cụ thể này.
Máy trạm nhẹ: Người dùng thực sự có thể xác minh Chuỗi mà họ đang tương tác, thay vì chỉ tin tưởng vào nhà cung cấp RPC. Helios của A16z Crypto thực hiện điều này cho chính Ethereum, nhưng chúng ta cần mở rộng sự không tin cậy này sang L2. ERC-3668 (CCIP-read) là một chiến lược để đạt được điều này.
Cái nhìn về cách một máy trạm đơn giản cập nhật Chuỗi tiêu đề Ethereum của nó. Sau khi có Chuỗi tiêu đề, bạn có thể sử dụng bằng chứng Merkle để xác minh bất kỳ đối tượng trạng thái nào. Khi bạn có đối tượng trạng thái L1 chính xác, bạn có thể sử dụng bằng chứng Merkle (và có thể là chữ ký nếu bạn muốn kiểm tra xác nhận trước) để xác minh bất kỳ đối tượng trạng thái nào trên L2. Helios đã làm điều trước đây. Mở rộng sang thứ hai là một thách thức tiêu chuẩn hóa.
Ví Keystore: Ngày nay, nếu bạn muốn cập nhật các khóa kiểm soát ví hợp đồng thông minh, bạn phải thực hiện việc đó trên tất cả N Chuỗi mà ví đó đang bật. Ví kho khóa là công nghệ cho phép các khóa tồn tại ở một vị trí (trên L1 hoặc có thể sau này trên L2) và sau đó đọc từ bất kỳ L2 nào có bản sao của ví. Điều này có nghĩa là việc cập nhật chỉ cần diễn ra một lần. Để nâng cao hiệu quả, ví kho khóa yêu cầu L2 phải có cách đọc L1 được tiêu chuẩn hóa mà không tốn kém; hai đề xuất cho việc này là L1SLOAD và REMOESTATICCALL.
Sơ đồ cách điệu về cách hoạt động của ví kho khóa.
Ý tưởng "cầu nối token chung" cấp tiến hơn: hãy tưởng tượng một thế giới trong đó tất cả L2 là một bản tổng hợp bằng chứng xác thực, với mọi vị trí dành riêng cho Ethereum. Ngay cả trong thế giới này, việc chuyển tài sản"cục bộ" từ L2 này sang L2 khác yêu cầu rút và gửi tiền, đòi hỏi phải trả lượng lớn gas L1. Một phương pháp để giải quyết vấn đề này là tạo một bản tổng hợp tối thiểu được chia sẻ có chức năng duy nhất là duy trì số dư trong đó L2 sở hữu bao nhiêu loại token và cho phép số dư này được cập nhật chung thông qua sê-ri các giao dịch chéo. Hoạt động gửi L2 được bắt đầu bởi bất kỳ L2 nào. Điều này sẽ cho phép chuyển khoản chéo L2 diễn ra mà không phải trả gas L1 cho lần lần chuyển và không cần công nghệ dựa trên nhà cung cấp thanh khoản(chẳng hạn như ERC-7683).
Khả năng kết hợp đồng bộ: Cho phép các cuộc gọi đồng bộ xảy ra giữa một L2 và L1 cụ thể hoặc giữa nhiều L2. Điều này có thể giúp cải thiện hiệu quả tài chính của các giao thức Defi. Cái trước có thể được thực hiện mà không cần bất kỳ sự phối hợp chéo L2 nào; cái sau yêu cầu trình tự được chia sẻ. Tự động hóa dựa trên tổng hợp thân thiện với tất cả các công nghệ này.
Các kết nối với nghiên cứu hiện tại là gì?
Địa chỉ cụ thể của Chuỗi: ERC-3770: https://eips.ethereum.org/EIPS/eip-3770
ERC-7683: https://eips.ethereum.org/EIPS/eip-7683
RIP-7755: https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md
Thiết kế ví keystore cuộn: https://hackmd.io/@haichen/keystore
Helios: https://github.com/ a16z/helios
ERC-3668 (đôi khi được gọi là đọc CCIP): https://eips.ethereum.org/EIPS/eip-3668
Đề án"Xác nhận trước dựa trên (được chia sẻ)" của Justin Drake: https://ethresear.ch/t/based-preconfirmations/17353
L1SLOAD (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388
Những lời kêu gọi lạc quan từ xa: https://github.com/ethereum- Optimism/ecosystem-contributions/issues/76
AggLayer, trong đó gồm ý tưởng về cầu nối mã thông báo được chia sẻ: https://github.com/AggLayer
Cần phải làm gì nữa, cần phải đánh đổi những gì?
Nhiều ví dụ trên phải đối mặt với vấn đề nan giải về tiêu chuẩn khi nào cần chuẩn hóa và lớp nào cần chuẩn hóa. Nếu bạn tiêu chuẩn hóa quá sớm, bạn có thể rủi ro một giải pháp kém chất lượng. Nếu bạn tiêu chuẩn hóa quá muộn, bạn có nguy cơ gây ra sự phân mảnh không cần thiết. Trong một số trường hợp, có những giải pháp ngắn hạn kém hiệu quả hơn nhưng dễ thực hiện hơn và có những giải pháp dài hạn “cuối cùng cũng đúng” nhưng mất khá nhiều thời gian để thực hiện.
Điều độc đáo ở phần này là nhiệm vụ này không chỉ là vấn đề kỹ thuật: chúng còn (có lẽ là hầu hết!) vấn đề xã hội. Họ cần L2 và ví để hợp tác với L1. Khả năng giải quyết thành công vấn đề này của chúng tôi là một bài kiểm tra khả năng của chúng tôi trong việc đoàn kết với nhau như một cộng đồng.
Nó tương tác với các phần khác của lộ trình như thế nào?
Hầu hết các đề xuất này đều là cấu trúc "cấp cao hơn" và do đó sẽ không có nhiều tác động đến việc cân nhắc L1. Một ngoại lệ là sắp xếp chia sẻ, điều này có tác động mạnh mẽ đến MEV.
Mở mở rộng thực thi trên L1
Chúng ta đang cố gắng giải quyết vấn đề gì?
Nếu L2 trở nên có mở rộng và thành công rất cao, nhưng L1 vẫn chỉ có thể xử lý một số lượng giao dịch rất nhỏ, thì có thể có một số rủi ro Ethereum :
Tình hình kinh tế của tài sản ETH trở nên nguy hiểm hơn, từ đó ảnh hưởng đến tính bảo mật lâu dài của mạng.
Nhiều L2 được hưởng lợi từ mối quan hệ chặt chẽ với hệ sinh thái tài chính phát triển cao trên L1 và nếu hệ sinh thái này bị suy yếu đáng kể, động lực trở thành L2 (chứ không phải L1 độc lập) sẽ yếu đi.
Sẽ mất nhiều thời gian để L2 có được sự đảm bảo an ninh giống hệt như L1.
Nếu L2 không thành công (ví dụ do hoạt động độc hại hoặc nhà điều hành biến mất), người dùng vẫn cần phải thông qua L1 để khôi phục tài sản của mình. Do đó, L1 cần phải đủ mạnh để có thể thực sự xử lý phần cuối L2 cực kỳ phức tạp và lộn xộn ít nhất là đôi khi.
Vì những lý do này, việc tiếp tục mở rộng L1 và đảm bảo rằng nó có thể tiếp tục thích ứng với ngày càng nhiều mục đích sử dụng là rất có giá trị.
Nó là gì và nó hoạt động như thế nào?
Phương pháp dễ nhất mở rộng là chỉ cần tăng giới hạn gas . Tuy nhiên, điều này rủi ro tập trung hóa L1, do đó làm suy yếu một thuộc tính quan trọng khác khiến Ethereum L1 trở nên mạnh mẽ: độ tin cậy của nó như một lớp cơ sở vững chắc. Hiện đang có cuộc tranh luận về việc mức tăng giới hạn gas đơn giản có bền vững đến mức nào và điều này cũng sẽ thay đổi dựa trên việc triển khai các công nghệ khác để giúp xác minh các khối lớn hơn dễ dàng hơn (ví dụ: hết hạn lịch sử , không trạng thái, Bằng chứng về tính hiệu quả của L1 EVM) . Một điều quan trọng khác cần được cải tiến liên tục là hiệu quả của phần mềm máy trạm Ethereum , ngày nay đã được tối ưu hóa hơn so với 5 năm trước. Chiến lược tăng giới hạn gas L1 hiệu quả sẽ liên quan đến việc đẩy nhanh các kỹ thuật xác minh này.
Một chiến lược mở rộng khác liên quan đến việc xác định các chức năng và loại tính toán cụ thể có thể được thực hiện rẻ hơn mà không ảnh hưởng đến tính phân cấp của mạng hoặc các thuộc tính bảo mật của nó. Ví dụ về điều này bao gồm:
EOF - Định dạng mã byte EVM mới thân thiện hơn với phân tích tĩnh và cho phép triển khai nhanh hơn. Khi tính đến những hiệu quả này, mã byte EOF có thể mang lại chi phí gas thấp hơn.
Định giá gas đa chiều - Việc thiết lập các giới hạn và phí cơ bản riêng biệt cho tính toán, dữ liệu và lưu trữ có thể làm tăng công suất trung bình của Ethereum L1 mà không tăng công suất tối đa (do đó tạo ra rủi ro bảo mật mới).
Giảm chi phí gas nhìn lên các opcode và tiền biên dịch gas - Lịch sử , chúng tôi đã thực hiện nhiều đợt tăng chi phí gas cho một số hoạt động được định giá thấp nhất định để tránh các cuộc tấn công từ chối dịch vụ. Điều chúng tôi làm ít hơn nhưng có thể làm nhiều hơn là giảm chi phí gas cho các hoạt động được định giá quá cao của chúng tôi. Ví dụ: phép cộng rẻ hơn nhiều so với phép nhân, nhưng các mã ADD và MUL hiện có giá như nhau. Chúng tôi có thể làm cho ADD rẻ hơn và thậm chí các opcode đơn giản hơn như PUSH cũng rẻ hơn. Nhìn chung có nhiều EOF hơn.
EVM-MAX và SIMD : EVM-MAX (" Mở rộng số học mô-đun -đun") là một đề xuất nhằm cho phép toán học mô-đun số lớn nguyên bản hiệu quả hơn như một mô-đun riêng biệt của EVM. Các giá trị được tính bằng phép tính EVM-MAX chỉ có thể được truy cập bằng các opcode EVM-MAX khác trừ khi được xuất có chủ ý; điều này cho phép có nhiều không gian hơn để lưu trữ các giá trị này ở định dạng được tối ưu hóa. SIMD ("Một lệnh đa dữ liệu") là một đề xuất cho phép thực hiện hiệu quả các lệnh giống nhau trên một mảng giá trị. Cùng với nhau, cả hai có thể được sử dụng với EVM để tạo ra bộ đồng xử lý mạnh mẽ có thể được sử dụng để triển khai các hoạt động crypto hiệu quả hơn. Điều này đặc biệt hữu ích cho các giao thức bảo mật và hệ thống chứng minh L2, vì vậy nó sẽ giúp mở rộng L1 và L2.
Những cải tiến này sẽ được thảo luận chi tiết hơn trong bài viết tiếp theo về Splurge.
Cuối cùng, chiến lược thứ ba là tổng hợp gốc (hoặc "tập hợp tích hợp"): về cơ bản, tạo ra nhiều bản sao của EVM chạy song song, từ đó hình thành một mô hình tương đương với những gì tập hợp có thể cung cấp, nhưng tích hợp nguyên bản hơn theo thỏa thuận .
Các kết nối với nghiên cứu hiện tại là gì?
Lộ trình mở rộng Ethereum L1 của Polynya: https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ
Định giá gas đa chiều: https://vitalik.eth.limo/general/2024/05/09/multidim.html
EIP-7706: https://eips.ethereum.org/EIPS/eip-7706
EOF: https://evmobjectformat.org/
EVM-MAX: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168
SIMD: https://eips.ethereum.org/EIPS/eip-616
Tóm tắt gốc: https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE
Phỏng vấn Max Resnick về giá trị của mở rộng L1: https://x.com/BanklessHQ/status/1831319419739361321
Justin Drake về mở rộng bằng SNARK và các bản tổng hợp gốc: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/
Cần phải làm gì nữa, cần phải đánh đổi những gì?
Có ba chiến lược để mở rộng quy mô L1, có thể được thực hiện riêng lẻ hoặc song song:
Cải tiến công nghệ (ví dụ: mã máy trạm, máy trạm không trạng thái, lịch sử hết hạn) để giúp L1 xác minh dễ dàng hơn, sau đó tăng giới hạn gas
Giảm chi phí cho các hoạt động cụ thể và tăng công suất trung bình mà không làm tăng rủi ro trong trường hợp xấu nhất
Bản tổng hợp gốc (tức là "tạo N bản sao song song của EVM", mặc dù có thể mang lại cho nhà phát triển rất nhiều tính linh hoạt về mặt tham số để triển khai các bản sao)
Cần hiểu rằng đây là những công nghệ khác nhau với những đánh đổi khác nhau. Ví dụ: các bản tổng hợp gốc có nhiều điểm yếu giống như các bản tổng hợp thông thường về khả năng kết hợp: bạn không thể gửi một giao dịch để thực hiện các hoạt động một cách đồng bộ trên nhiều giao dịch, giống như bạn có thể làm với các hợp đồng trên cùng một L1 (hoặc L2). Việc tăng giới hạn Gas sẽ lấy đi các lợi ích khác có thể đạt được bằng cách làm cho L1 dễ xác minh hơn, chẳng hạn như tăng tỷ lệ người dùng chạy nút xác thực và tăng số lượng người đặt cọc riêng lẻ. Việc làm cho các hoạt động cụ thể trong EVM rẻ hơn (tùy thuộc vào cách chúng được thực hiện) có thể làm tăng độ phức tạp tổng thể của EVM.
Một câu hỏi lớn mà bất kỳ lộ trình mở rộng L1 nào cũng cần trả lời là: Viễn cảnh mong đợi cuối cùng cho L1 và L2 là gì? Rõ ràng, việc mọi thứ xảy ra trên L1 thật là nực cười: trường hợp sử dụng tiềm năng là hàng trăm nghìn giao dịch mỗi giây, điều này sẽ khiến L1 hoàn toàn không thể xác minh được (trừ khi chúng ta đi theo con đường tổng hợp gốc). Nhưng chúng tôi cần một số hướng dẫn để có thể đảm bảo rằng chúng tôi không tạo ra tình huống tăng giới hạn gas lên gấp 10 lần, gây tổn hại nghiêm trọng phi tập trung của Ethereum L1 và thấy rằng chúng tôi vừa bước vào một thế giới thay vì 99% hoạt động là trên L2, 90% hoạt động là trên L2, do đó, kết quả trông gần như giống nhau, ngoại trừ sự mất mát hầu như không thể đảo ngược về tính đặc hiệu L1 của Ethereum.
Đề xuất quan quan điểm về “phân công lao động” giữa L1 và L2
Nó tương tác với các phần khác của lộ trình như thế nào?
Thu hút nhiều người dùng hơn vào L1 có nghĩa là không chỉ cải thiện quy mô mà còn cải thiện các khía cạnh khác của L1. Điều này có nghĩa là sẽ có nhiều MEV hơn ở L1 (thay vì chỉ là vấn đề ở L2), do đó việc giải quyết nó một cách rõ ràng là cấp bách hơn. Nó làm tăng đáng kể giá trị của thời gian đánh bạc nhanh trên L1. Nó cũng phụ thuộc rất nhiều vào quá trình xác minh L1 ("The Verge") diễn ra tốt đẹp.
