Ở đầu, Ethereum có hai chiến lược mở rộng trong lộ trình của mình. Một (ví dụ xem bài báo sớm nàytừ năm 2015) là "sharding": thay vì xác minh và lưu trữ tất cả các giao dịch trong chuỗi, mỗi nút chỉ cần xác minh và lưu trữ một phần nhỏ của các giao dịch. Đây là cách mà bất kỳ mạng ngang hàng nào khác (ví dụ: BitTorrent) cũng hoạt động, vì vậy chắc chắn chúng ta có thể làm cho các chuỗi khối hoạt động theo cùng một cách. Một trong những cách khác là các giao thức tầng 2: các mạng sẽ đặt trên cơ sở của Ethereum một cách cho phép chúng hoàn toàn hưởng lợi từ tính bảo mật của nó, trong khi giữ phần lớn dữ liệu và tính toán ra khỏi chuỗi chính. "Các giao thức tầng 2" có nghĩa làkênh trạng tháinăm 2015, Plasmanăm 2017, và sau đó rollupsvào năm 2019. Rollups mạnh mẽ hơn so với các kênh trạng thái hoặc Plasma, nhưng họ đòi hỏi một lượng lớn băng thông dữ liệu on-chain. May mắn thay, vào năm 2019, nghiên cứu phân mảnh đã giải quyếtvấn đề xác minh “khả năng truy cập dữ liệu” ở quy mô lớnKết quả là, hai con đường đã hội tụ, và chúng tôi đã nhận được lộ trình tập trung vào rollupmà vẫn là chiến lược mở rộng của Ethereum ngày nay.

The Surge, 2023 roadmap edition.

Lộ trình tập trung vào rollup đề xuất một phân chia công việc đơn giản: Ethereum L1 tập trung vào việc trở thành một lớp cơ sở mạnh mẽ và phi tập trung, trong khi L2s đảm nhận nhiệm vụ giúp hệ sinh thái mở rộng. Đây là một mẫu hình tái diễn khắp mọi nơi trong xã hội: hệ thống tòa án (L1) không phải là để trở nhanh chóng và hiệu quả cực cao, nó tồn tại để bảo vệ hợp đồng và quyền sở hữu, và là trách nhiệm của doanh nhân (L2) xây dựng trên cơ sở đóvững chắc căn cứ lớpvà đưa loài người đến (ẩn dụ và hiển nhiên) sao Hỏa.

Năm nay, lộ trình tập trung vào rollup đã đạt được những thành công quan trọng: băng thông dữ liệu Ethereum L1 đã tăng lên rất nhiều với EIP-4844 blobs, và hiện tại có nhiều EVM rollups ở giai đoạn 1. Một rấtcài đặt phân mảnh đa dạng và đa nguyên tố, nơi 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, giờ đây đã trở thành hiện thực. Nhưng như chúng ta đã thấy, đi theo con đường này có một số thách thức độc đáo của riêng nó. Và vì vậy, bây giờ nhiệm vụ của chúng tôi là hoàn thành lộ trình tập trung vào rollup và giải quyết những vấn đề này, trong khi vẫn duy trì sự mạnh mẽ và phi tập trung làm cho Ethereum L1 trở nên đặc biệt.

The Surge: mục tiêu chính

• 100,000+ TPS trên L1+L2
• Bảo tồn sự phi tập trung và tính mạnh mẽ của L1
• Ít nhất một số L2 hoàn toàn thừa kế các đặc tính cốt lõi của Ethereum (không cần tin tưởng, mở, chống kiểm duyệt)
• Tích hợp tối đa giữa các L2. Ethereum nên cảm thấy như một hệ sinh thái duy nhất, không phải là 34 chuỗi khối khác nhau.

Trong chương này

• Ngoại lệ: ba đẳng tăng cượng
• Tiến triển tiếp trong mẫu lấy sẵn dữ liệu
• Nén dữ liệu
• Plasma Tổng quát
• Hệ thống chứng minh L2 đang trưởng thành
• Tích hợp chéo L2 và cải thiện UX
• Mở rộng thực hiện trên L1

Ngoài ra: vấn đề ba khía cạnh về khả năng mở rộng

Vấn đề ba khía cạnh về khả năng mở rộng là một ý tưởng được giới thiệu vào năm 2017, người ta lập luận rằng có một sự căng thẳng giữa ba tính chất của một blockchain: phân quyền (cụ thể hơn: chi phí thấp để chạy một node), khả năng mở rộng (cụ thể hơn: số giao dịch được xử lý cao), và bảo mật (cụ thể hơn: một kẻ tấn công cần phải phá hoại một phần lớn các node trong toàn bộ mạng để thậm chí một giao dịch đơn lẻ cũng thất bại).

Đáng chú ý, ba điểm hạn chế không phải là một định lý, và bài viết giới thiệu ba điểm hạn chế không đi kèm với một chứng minh toán học. Nó chỉ đưa ra một lập luận toán học gợi ý: nếu một nút thân thiện với sự phân quyền (ví dụ: laptop 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ì hoặc (i) mỗi giao dịch chỉ được nhìn thấy bởi 1/k số nút, điều này ngụ ý một kẻ tấn công chỉ cần phá hoại một số nút để tiến hành một giao dịch xấu, hoặc (ii) các nút của bạn sẽ mạnh mẽ và chuỗi của bạn không phân quyền. Mục đích của bài viết không phải để chứng minh việc phá vỡ ba điểm hạn chế là không thể; thay vào đó, mục đích của nó là để cho thấy việc phá vỡ ba điểm hạn chế là khó - nó đòi hỏi cách nghĩ ngoài hộp mà lập luận ngụ ý.

Trong nhiều năm qua, đã phổ biến khi một số chuỗi hoạt động cao cấp tuyên bố giải quyết tam giác mâu thuẫn mà không cần thực hiện bất kỳ điều gì thông minh ở cấp độ kiến trúc cơ bản, thường bằng cách sử dụng các chiêu thức kỹ thuật 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 một nút trên các chuỗi như vậy luôn kết thúc khó khăn hơn nhiều so với trên Ethereum.Bài viết nàyđi vào một số điều tinh tế vì sao điều này lại xảy ra (và vì vậy, tại sao kỹ sư phần mềm L1 client không thể mở rộng Ethereum một cách độc lập).

Tuy nhiên, sự kết hợp giữa việc lấy mẫu sẵn có dữ liệu và SNARKs đã giải quyết vấn đề tam đạng: nó cho phép một bên thứ ba xác minh rằng một lượng dữ liệu nào đó có sẵn, và một số bước tính toán đã được thực hiện đúng, trong khi chỉ tải về một phần nhỏ của dữ liệu đó và thực hiện một lượng tính toán nhỏ hơn nhiều. SNARKs không đòi hỏi tin tưởng. Việc lấy mẫu sẵn có dữ liệu có tính tinh tế.Mô hình tin cậy một số N, nhưng nó bảo tồn tính chất cơ bản mà các chuỗi không thể mở rộng có, đó là ngay cả một cuộc tấn công 51% cũng không thể buộc các khối xấu được chấp nhận bởi mạng lưới.

Một cách khác để giải quyết vấn đề tam đa là kiến trúc Plasma, sử dụng các kỹ thuật thông minh để đẩy trách nhiệm theo dõi sự có sẵn của dữ liệu cho người dùng một cách tương thích với động lực. Trong thời kỳ từ năm 2017-2019, khi tất cả những gì chúng ta có để mở rộng tính toán là chứng minh gian lận, Plasma bị hạn chế rất nhiều trong việc mà nó có thể an toàn thực hiện, nhưng việc phổ cập SNARKs đã làm cho kiến trúc Plasma có khả năng hơn rất nhiềucho một loạt các trường hợp sử dụng rộng hơn so với trước đây.

Tiến triển tiếp theo trong việc lấy mẫu sẵn có dữ liệu

Chúng tôi đang giải quyết vấn đề gì?

Vào ngày 13 tháng 3 năm 2024, khi Nâng cấp Dencun Đi vào hoạt động, blockchain Ethereum có ba ~ 125 kB "blobs" trên mỗi khe cắm 12 giây, hoặc ~ 375 kB trên mỗi khe băng thông khả dụng dữ liệu. Giả sử dữ liệu giao dịch được công bố trực tiếp trên chuỗi, chuyển khoản ERC20 là ~ 180 byte và do đó, TPS tối đa của bản tổng hợp trên Ethereum là:

375000 / 12 / 180 = 173.6 TPS

Nếu chúng ta thêm dữ liệu cuộc gọi của Ethereum (tối đa lý thuyết: 30 triệu gas mỗi khe / 16 gas mỗi byte = 1.875.000 byte mỗi khe), điều này sẽ trở thành 607 TPS. 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ẽ cho chúng ta 463-926 TPS trong dữ liệu cuộc gọi.

Đây là một bước tăng đáng kể so với Ethereum L1, nhưng chưa đủ. Chúng tôi muốn mở rộng khả năng mở rộng nhiều hơn nữa. Mục tiêu trung hạn của chúng tôi là 16 MB mỗi khe cắm, nếu kết hợp với cải tiến trong nén dữ liệu rollup sẽ mang lại cho chúng tôi khoảng ~58,000 TPS.

Đó là gì và nó hoạt động như thế nào?

PeerDAS là một triển khai tương đối đơn giản của "lấy mẫu 1D". Mỗi blob trong Ethereum là một đa thức độ-4096 trên trường nguyên tố 253 bit. Chúng tôi phát sóng "cổ phần" của đa thức, trong đó mỗi phần bao gồm 16 đánh giá tại 16 tọa độ liền kề được lấy từ tổng số 8192 tọa độ. Bất kỳ 4096 trong số 8192 đánh giá (với các thông số được đề xuất hiện tại: bất kỳ 64 trong số 128 mẫu có thể) có thể phục hồi blob.

PeerDAS hoạt động bằng cách khiến mỗi khách hàng lắng nghe trên một số mạng con nhỏ, trong đó mạng con thứ i phát sóng mẫu thứ i của bất kỳ đống dữ liệu nào, và đồng thời yêu cầu đống dữ liệu trên các mạng con khác mà nó cần bằng cách yêu cầu các đồng nghiệp của mình trong mạng p2p toàn cầu (những người sẽ lắng nghe trên các mạng con khác nhau). Một phiên bản cẩn thận hơn, SubnetDAS, chỉ sử dụng cơ chế mạng con, mà không cần tới lớp bổ sung để hỏi các đồng nghiệp. Một đề xuất hiện tại là để các nút tham gia chứng minh cổ phần sử dụng SubnetDAS, và để các nút khác (tức là “khách hàng”) sử dụng PeerDAS.

Về lý thuyết, chúng ta có thể mở rộng việc lấy mẫu 1D khá xa: nếu chúng ta tăng số lượng blob tối đa lên 256 (vì vậy, mục tiêu là 128), thì chúng ta sẽ đạt được mục tiêu 16 MB của chúng ta trong khi việc lấy mẫu sẵn có dữ liệu chỉ tốn cho mỗi nút 16 mẫu128 blobs512 byte mỗi mẫu mỗi khối = 1 MB dữ liệu băng thông mỗi khe cắm. Điều này chỉ đúng trong phạm vi dung nạp của chúng tôi: có thể thực hiện được, nhưng điều đó có nghĩa là các máy khách bị hạn chế 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 một chút bằng cách giảm số lượng khối và tăng kích thước khối, nhưng điều này sẽ làm cho việc tái tạo đắt đỏ hơn.

Và cuối cùng, chúng tôi muốn đi xa hơn, và thực hiệnLấy mẫu 2D, hoạt động bằng cách lấy mẫu ngẫu nhiên không chỉ trong các blob, mà còn giữa các blob. Các tính chất tuyến tính của cam kết KZG được sử dụng để “mở rộng” tập hợp các blob trong một khối với một danh sách các “blob ảo” mới mà mã hóa dư thừa cùng thông tin.

Lấy mẫu 2D. Nguồn: a16z crypto

Điều quan trọng, tính toán sự mở rộng của cam kết không đòi hỏi phải có các blob, vì vậy hệ thống này cơ bản là thân thiện với việc xây dựng khối phân tán. Node 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 DAS để xác minh sự có sẵn của các blob. 1D DAS cũng thân thiện với việc xây dựng khối phân tán theo bản chất.

Có những liên kết nào đến nghiên cứu hiện tại?

• Bài đăng ban đầu giới thiệu khả năng sẵn có dữ liệu (2018): https://github.com/ethereum/research/wiki/Chú-thích-về-sự-sẵn-có-dữ-liệu-và-mã-hoá-xóa
• Bài báo theo dõi: https://arxiv.org/abs/1809.09044
• Bài viết giải thích về DAS, mô hình:https://www.paradigm.xyz/2022/08/das
• Sẵn có 2D với cam kết KZG: 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-using-battle-tested-p2p-components/16541 , và giấy: https://eprint.iacr.org/2024/1362
• Bài thuyết trình về PeerDAS do Francesco thực hiện: https://www.youtube.com/watch?v=WOdpO1tH_Us
• 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 vấn đề về khả năng phục hồi trong lấy mẫu 2D: https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256

Còn gì để làm, và những sự đánh đổi là gì?

Bước tiếp theo ngay lập tức là hoàn thành việc triển khai và triển khai PeerDAS. Từ đó, điều quan trọng là tiếp tục tăng số lượng blob trên PeerDAS một cách tiến bộ trong khi cẩn thận quan sát mạng và cải thiện phần mềm để đảm bảo an toàn. Đồng thời, chúng tôi muốn có nhiều công việc học thuật hơn về việc hình thành PeerDAS và các phiên bản khác của DAS và tương tác của nó với các vấn đề như an toàn luật lựa chọn fork.

Hơn nữa trong tương lai, chúng ta cần nhiều công việc hơn để tìm ra phiên bản lý tưởng của DAS 2D và chứng minh các đặc tính an toàn của nó. Chúng tôi cũng muốn cuối cùng chuyển từ KZG sang một giải pháp thay thế không cần thiết lập lượng tử, đá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 "brute force" đắt tiền của việc sử dụng STARK đệ quy để tạo ra bằng chứng về tính hợp lệ để tái tạo các hàng và cột cũng không đủ, bởi vì trong khi về mặt kỹ thuật, STARK có kích thước băm O (log (n) * log (log (n)) (với STIR) trong thực tế, một STARK gần bằng cỡ một khối toàn bộ.

Những con đường thực tế mà tôi thấy cho dài hạn là:

• Thực hiện 2D DAS lý tưởng
• Tiếp tục với 1D DAS, hy sinh hiệu suất băng thông mẫu và chấp nhận một ngưỡng dữ liệu thấp vì sự đơn giản và mạnh mẽ
• (Chuyển đổi cứng) từ bỏ DA, và hoàn toàn om sòm Plasma như một kiến trúc tầng 2 chính chúng tôi đang tập trung vào

Chúng ta có thể xem những điều này theo một phổ thong mại:

Lưu ý rằng sự lựa chọn này vẫn tồn tại ngay cả khi chúng ta quyết định mở rộng thực thi trên L1 trực tiếp. Điều này xảy ra vì nếu L1 phải xử lý nhiều giao dịch mỗi giây, các khối L1 sẽ trở nên rất lớn, và các máy khách sẽ muốn một cách hiệu quả để xác minh rằng chúng là chính xác, vì vậy chúng ta sẽ phải sử dụng cùng công nghệ mà làm cho rollups mạnh mẽ (ZK-EVM và DAS) tại L1.

Làm thế nào nó tương tác với các phần khác của lộ trình?

Nhu cầu về 2D DAS được giảm bớt một phần, hoặc ít nhất là trì hoãn, nếu việc nén dữ liệu (xem dưới đây) được thực hiện, và nó càng được giảm bớt hơn nếu Plasma được sử dụng rộng rãi. DAS cũng đặt ra một 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: trong khi DAS lí thuyết thân thiện với việc tái tạo phân tán, điều này cần phải được kết hợp trong thực tế vớidanh sách bao gồmcác đề xuất và cơ chế lựa chọn fork xung quanh chúng.

Nén dữ liệu

Chúng ta đang giải quyết vấn đề gì?

Mỗi giao dịch trong một rollup chiếm một lượng dữ liệu đáng kể trên chuỗi: một việc chuyển ERC20 mất khoảng 180 byte. Ngay cả khi có mẫu dữ liệu khả dụng lý tưởng, điều này đặt ra một giới hạn về tính mở rộng của các giao thức tầng 2. Với 16 MB mỗi khe, chúng ta có:

16000000 / 12 / 180 = 7407 TPS

Điều gì nếu ngoài việc giải quyết tử số, chúng ta cũng có thể giải quyết mẫu số, và làm cho mỗi giao dịch trong một cuộn giảm số byte trên chuỗi?

Đó là gì và nó hoạt động như thế nào?

Phần giải thích tốt nhất theo ý kiến của tôi là sơ đồ nàytừ hai năm trước:

Những lợi ích đơn giản nhất chỉ là nén byte không: thay thế mỗi chuỗi byte không đến bằng hai byte đại diện cho số lượng byte không đó. Để tiến xa hơn, chúng tôi tận dụng các thuộc tính cụ thể của giao dịch:

• Tích hợp chữ ký - chúng tôi chuyển từ chữ ký ECDSA sang chữ ký BLS, có tính chất rằng nhiều chữ ký có thể được kết hợp lại thành một chữ ký duy nhất chứng minh cho tính hợp lệ của tất cả các chữ ký ban đầu. Điều này không được xem xét cho L1 vì chi phí tính toán của việc xác minh, ngay cả với tích hợp, cao hơn, nhưng trong môi trường thiếu dữ liệu như L2s, chúng có lẽ hợp lý.ERC-4337đưa ra một con đường để thực hiện điều này.
• Thay thế địa chỉ bằng con trỏ - nếu một địa chỉ đã được sử dụng trước đó, chúng ta có thể thay thế địa chỉ 20 byte bằng một con trỏ 4 byte đến một vị trí trong lịch sử. Điều này cần thiết để đạt được những lợi ích lớn nhất, mặc dù nó tốn công sức để triển khai, vì nó yêu cầu (ít nhất là một phần) lịch sử của blockchain trở thành một phần hiệu quả của trạng thái.
• Tùy chỉnh chuỗi hóa cho các giá trị giao dịch - hầu hết các giá trị giao dịch có rất ít chữ số, ví dụ: 0.25 ETH được biểu diễn dưới dạng 250.000.000.000.000.000 wei. Gas max-basefees và priority fees cũng hoạt động tương tự. 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 gàng với một định dạng dấu phẩy động tùy chỉnh, hoặc thậm chí là một từ điển các giá trị phổ biến đặc biệt.

Có những liên kết nào đến nghiên cứu hiện có?

• Khám phá từ sequence.xyz: https://sequence.xyz/blog/compressing-calldata
• Hợp đồng được tối ưu hóa dữ liệu cuộc gọi cho L2s, từ ScopeLift: https://github.com/ScopeLift/l2-optimizoooors
• Một chiến lược thay thế - cuộn tròn dựa trên chứng minh tính hợp lệ (còn gọi là cuộn tròn ZK) đăng các sự khác biệt về trạng thái thay vì giao dịch: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975
• Ví BLS - một triển khai của việc tổng hợp BLS thông qua ERC-4337: https://github.com/getwax/bls-wallet

Còn lại để làm gì, và sự đánh đổi là gì?

Việc chính còn lại để thực sự thực hiện các kế hoạch trên. Các sự đánh đổi chính là:

• Chuyển sang chữ ký BLS đòi hỏi nỗ lực đáng kể và làm giảm tính tương thích với chip phần cứng đáng tin cậy có thể tăng cường bảo mật. Một lớp bọc ZK-SNARK xung quanh các hệ thống chữ ký khác có thể được sử dụng để thay thế điều này.
• Nén động (ví dụ: thay đổi địa chỉ bằng con trỏ) làm phức tạp mã khách hàng.
• Đăng trạng thái khác nhau vào chuỗi thay vì giao dịch làm giảm khả năng kiểm toán và làm cho nhiều phần mềm (ví dụ: trình khám phá khối) không hoạt động.

Làm thế nào nó tương tác với các phần khác của lộ trình?

Việc áp dụng ERC-4337, và cuối cùng là việc đưa một phần của nó vào trong các L2 EVMs, có thể nhanh chóng triển khai các kỹ thuật tổng hợp. Việc đưa một phần của ERC-4337 vào L1 có thể làm nhanh chóng việc triển khai nó trên L2s.

Plasma Tổng quát

Chúng tôi đang giải quyết vấn đề gì?

Ngay cả với các blog 16 MB và nén dữ liệu, 58.000 TPS không nhất thiết đủ để hoàn toàn chiếm lĩnh thanh toán người tiêu dùng, mạng xã hội phi tập trung hoặc các lĩnh vực có băng thông cao khác, và điều này trở nên đặc biệt đúng nếu chúng ta bắt đầu xem xét vấn đề bảo mật, điều này có thể làm giảm tính mở rộng đi từ 3-8 lần. Đối với các ứng dụng có khối lượng cao, giá trị thấp, một lựa chọn hiện nay là mộtvalidium, giữ dữ liệu ngoài chuỗi khối và có mô hình bảo mật đặc biệt thú vị, trong đó người điều hành không thể lấy cắp tiền của người dùng, nhưng họ có thể biến mất và tạm thời hoặc vĩnh viễn đóng băng tất cả tiền của người dùng. Nhưng chúng ta có thể làm tốt hơn được.

Đó là gì và nó hoạt động như thế nào?

Plasma là một giải pháp mở rộng quy mô liên quan đến một nhà điều hành xuất bản các khối offchain và đặt gốc Merkle của các khối đó vào chuỗi (trái ngược với rollup, nơi toàn bộ khối được đặt trên chuỗi). Đối với mỗi khối, nhà điều hành 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 đối với tài sản của người dùng đó. Người dùng có thể rút tài sản của mình bằng cách cung cấp chi nhánh Merkle. Điều quan trọng, chi nhánh này không phải bắt nguồn từ trạng thái mới nhất - vì lý do này, ngay cả khi tính khả dụng của dữ liệu không thành công, người dùng vẫn có thể khôi phục tài sản của mình bằng cách rút trạng thái mới nhất mà họ có sẵn. Nếu người dùng gửi một nhánh không hợp lệ (ví dụ: thoát khỏi mộ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 một tài sản từ không khí), một cơ chế thách thức onchain có thể phân xử tài sản đó thuộc về ai.

Một biểu đồ của chuỗi Plasma Cash. Các giao dịch chi tiêu đồng xu i được đặt vào 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 đang 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 sớm của Plasma chỉ có thể xử lý trường hợp thanh toán và không thể tổng quát hóa hiệu quả hơn. Nếu chúng ta yêu cầu mỗi gốc được xác minh bằng một SNARK, Plasma trở nên mạnh mẽ hơn nhiều. Mỗi trò chơi thách thức có thể được đơn giản hóa đáng kể, vì chúng ta loại bỏ hầu hết các con đường có thể để toán tử gian lận. Các con đường mới cũng mở ra để cho phép các kỹ thuật Plasma được mở rộng đến một lớp tài sản tổng quát hơn nhiều. Cuối cùng, trong trường hợp toán tử không gian lận, người dùng có thể rút tiền của họ ngay lập tức, mà không cần phải chờ đợi một chu kỳ thách thức một tuần.

Một cách (không phải cách duy nhất) để tạo một chuỗi plasma EVM: sử dụng một ZK-SNARK để xây dựng một cây UTXO song song phản ánh những thay đổi cân bằng được thực hiện bởi EVM, và xác định một ánh xạ duy nhất của những gì là “đồng xu giống nhau” tại các điểm khác nhau trong lịch sử. Một cấu trúc Plasma sau đó có thể được xây dựng trên cơ sở đó.

Một hiểu biết then chốt 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 nhỏ tài sản (ví dụ, ngay cả chỉ là những đồng tiền chưa di chuyển trong tuần qua), bạn đã cải thiện đáng kể so với tình trạng hiện tại của EVM siêu mở rộ, đó là một validium hợp lệ.

Một lớp cấu trúc khác là plasma lai / rollups, chẳng hạn như Intmax. Những công trình 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 làm như vậy, bạn sẽ có các thuộc tính nằm đâu đó giữa plasma và rollups: trong trường hợp Intmax, bạn sẽ có một mức độ mở rộng và bảo mật rất cao, tuy nhiên, trong thế giới 16 MB, khả năng chứa lý thuyết được giới hạn vào khoảng 16.000.000 / 12 / 5 = 266.667 TPS.

Có những liên kết nào đến nghiên cứu hiện có?

• Bài báo Plasma gốc: https://plasma.io/plasma-deprecated.pdf
• Plasma Cash: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
• Plasma Cashflow: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#🚪-Exit
• Intmax (2023): https://eprint.iacr.org/2023/1082

Còn gì để làm, và sự đánh đổi là gì?

Nhiệm vụ chính còn lại là đưa các hệ thống Plasma vào sản xuất. Như đã đề cập ở trên, “plasma vs validium” không phải là một hệ số nhị phân: bất kỳ validium nào cũng có thể cải thiện tính an toàn của nó ít nhất một chút bằng cách thêm các tính năng Plasma vào cơ chế thoát. Phần nghiên cứu là về việc có được các tính chất tối ưu (về yêu cầu tin cậy, chi phí gas trường hợp xấu nhất L1, và sự dễ bị tấn công DoS) cho một EVM, cũng như các cấu trúc ứng dụng cụ thể khác. Ngoài ra, sự phức tạp về mặt khái niệm lớn hơn của Plasma so với rollups cần được giải quyết trực tiếp, cả thông qua nghiên cứu và thông qua việc xây dựng các frameworks tổng quát tốt hơn.

Sự đánh đổi chính trong việc sử dụng các thiết kế Plasma là chúng phụ thuộc nhiều hơn vào các nhà điều hành và khó khăn hơn trong việc tạo ra “dựa vào“, mặc dù thiết kế plasma/rollup hỗn hợp thường có thể 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?

Càng hiệu quả các giải pháp Plasma có thể, áp lực càng giảm đối với L1 phải có chức năng khả dữ liệu hiệu suất cao. Việc chuyển hoạt động sang L2 cũng giảm áp lực MEV trên L1.

Hệ thống chứng minh L2 đang trưởng thành

Chúng tôi đang giải quyết vấn đề gì?

Hôm nay, hầu hết các rollup vẫn chưa thực sự tin cậy; có một hội đồng an ninh có khả năng ghi đè hành vi của (lạc quan hoặc hợp lệ)hệ thống chứng minh. Trong một số trường hợp, hệ thống bằng chứng thậm chí không hoạt động, hoặc nếu có, nó chỉ có chức năng "tư vấn". Xa nhất phía trước là (i) một vài 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 thời điểm viết bài này, Optimism và Arbitrum, hai bản tổng hợp EVM đầy đủ đã đạt được cột mốc không tin cậy một phần được gọi là "giai đoạn 1". Lý do tại sao rollups đã không đi xa hơn là lo ngại về lỗi trong mã. Chúng tôi cần rollups không tin cậy, và vì vậy chúng tôi cần phải giải quyết vấn đề này trực tiếp.

Đó là gì và làm thế nào nó hoạt động?

Đầu tiên, hãy tóm tắt hệ thống “stage”, được giới thiệu lần đầu vào bài đăng này. Có những yêu cầu chi tiết hơn, nhưng tóm tắt là:

• Cấp độ 0: người dùng phải có thể chạy một nút và đồng bộ chuỗi. Không vấn đề nếu việc xác thực được tin cậy/ tập trung hoàn toàn.
• Giai đoạn 1: phải có một hệ thống chứng minh (không tin cậy) đảm bảo chỉ có giao dịch hợp lệ được chấp nhận. Cho phép có một hội đồng an ninh có thể ghi đè lên hệ thống chứng minh, nhưng chỉ với tỷ lệ bỏ phiếu ngưỡng 75%. Ngoài ra, một phần chặn quyền biểu quyết của hội đồng (tức là, 26%+) phải ở bên ngoài tòa nhà chính của công ty xây dựng rollup. Một cơ chế nâng cấp với các tính năng yếu hơn (ví dụ, một DAO) được phép, nhưng phải có một độ trễ đủ lớn để nếu nó chấp nhận một cập nhật độc hại, người dùng có thể rút tiền của họ trước khi nó trở thành hoạt động.
• Bước 2: phải có một hệ thống chứng minh (không tin cậy) đảm bảo chỉ có giao dịch hợp lệ được chấp nhận. Hội đồng an ninh chỉ được can thiệp trong trường hợp có lỗi có thể chứng minh trong mã nguồn, ví dụ, nếu hai hệ thống chứng minh dư thừa không đồng ý với nhau hoặc nếu một hệ thống chứng minh chấp nhận hai gốc trạng thái cuối cùng 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 đủ lâu, ví dụ, một tuần). Một cơ chế nâng cấp được phép, nhưng phải có độ trễ rất lớn.

Mục tiêu là đạt được giai đoạn 2. Thách thức chính trong việc đạt được giai đoạn 2 là có đủ niềm tin rằng hệ thống chứng minh thực sự đáng tin cậy đủ. Có hai cách 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 toán học và tính toán hiện đại để chứng minh rằng hệ thống chứng minh (lạc quan hoặc hợp lệ) chỉ chấp nhận các khối thỏa mãn đặc tả EVM. Các kỹ thuật này đã tồn tại từ nhiều thập kỷ trước, nhưng các tiến bộ gần đây như Lean 4đã khiến chúng trở nên thực tế hơn nhiều, và các tiến bộ trong việc chứng minh được hỗ trợ bởi trí tuệ nhân tạo có thể tăng tốc xu hướng này thêm nữa.
• Đa chứng minh: tạo ra nhiều hệ thống bằng chứng và đặt tiền vào đa chữ ký 2-of-3 (hoặc lớn hơn) giữa các hệ thống bằng chứng đó và hội đồng bảo mật (và / hoặc tiện ích khác với các giả định tin cậy, ví dụ: TEEs). Nếu các hệ thống chứng minh đồng ý, Hội đồng Bảo an không có quyền; Nếu họ không đồng ý, Hội đồng Bảo an chỉ có thể lựa chọn giữa một trong số họ, họ không thể đơn phương áp đặt câu trả lời của riêng mình.

Sơ đồ được tạo kiểu của một hệ thống chứng minh đa người chứng minh, kết hợp một hệ thống chứng minh lạc quan, một hệ thống chứng minh tính hợp lệ và một hội đồng an ninh.

Có những liên kết nào đến nghiên cứu hiện tại?

• EVM K Semantics (công việc xác minh hình thức từ năm 2017): https://github.com/runtimeverification/evm-semantics
• Trình bày về ý tưởng đa provers (2022): https://www.youtube.com/watch?v=6hfVzCWT6YI
• Taiko dự định sử dụng multi-proofs: https://docs.taiko.xyz/core-concepts/multi-proofs/

Còn lại những gì cần làm, và những sự đánh đổi là gì?

Đối với xác minh hình thức, rất nhiều. Chúng ta cần tạo ra một phiên bản đã được xác minh hình thức của một người chứng minh SNARK toàn bộ của một EVM. Đây là một dự án cực kỳ phức tạp, mặc dù đó là một trong những dự ánchúng tôi đã bắt đầu rồi. Có một mẹo giúp đơn giản hóa nhiệm vụ đáng kể: chúng ta có thể tạo một người chứng minh SNARK được xác minh hình thức của một VM tối thiểu, ví dụ.RISC-VhoặcCairo, và sau đó viết một phần mềm thực thi của EVM trong máy ảo tối giản đó (và chứng minh một cách hình thức sự tương đương của nó với một số đặc tả EVM khác).

Đối với multi-provers, còn hai phần chính còn lại. Thứ nhất, chúng ta cần đủ niềm tin vào ít nhất hai hệ thống chứng minh khác nhau, cả hai đều an toàn một cách hợp lý và nếu chúng hỏng, chúng sẽ hỏng vì lý do khác nhau và không liên quan (và vì vậy chúng sẽ không hỏng cùng một lúc). Thứ hai, chúng ta cần có một mức độ đảm bảo rất cao về logic cơ bản hợp nhất các hệ thống chứng minh. Đây là một phần mã nguồn nhỏ hơn nhiều. Có cách để làm cho nó cực kỳ nhỏ - chỉ cần lưu trữ tiền trong mộtHợp đồng đa chữ ký an toàncác bên ký kết là hợp đồng đại diện cho các hệ thống chứng minh cá nhân riêng lẻ - nhưng điều này đánh đổi với chi phí gas trên chuỗi cao. Một số sự cân bằng giữa hiệu suất và an toàn sẽ cần được tìm thấy.

Làm thế nào nó tương tác với các phần khác của lộ trình?

Chuyển hoạt động sang L2 giảm áp lực MEV trên L1.

Cải tiến tương tác qua L2 chéo nền tảng

Chúng ta đang giải quyết vấn đề gì?

Một thách thức lớn hiện nay với hệ sinh thái L2 là việc người dùng gặp khó khăn khi di chuyển. Hơn nữa, cách đơn giản nhất thường tái giới thiệu các giả định về niềm tin: cầu nối tập trung, các máy khách RPC, và cetera. Nếu chúng ta nghiêm túc với ý tưởng rằng L2 là một phần của Ethereum, chúng ta cần làm cho việc sử dụng hệ sinh thái L2 cảm thấy như việc sử dụng một hệ sinh thái Ethereum thống nhất.

Một ví dụ về bệnh lý xấu (và thậm chí nguy hiểm: Cá nhân tôi đã mất 100 đô la cho một lỗi lựa chọn chuỗi ở đây) cross-L2 UX - mặc dù đây không phải là lỗi của Polymarket, khả năng tương tác chéo L2 phải là trách nhiệm của ví và cộng đồng tiêu chuẩn Ethereum (ERC). Trong một hệ sinh thái Ethereum hoạt động tốt, việc gửi tiền từ L1 đến L2 hoặc từ L2 này sang L2 khác, sẽ giống như gửi tiền trong cùng một L1.

Đó là gì và nó hoạt động như thế nào?

Có nhiều danh mục cải tiến tương tác chéo-L2. Nói chung, cách để đề xuất chúng là nhận thấy rằng trong lý thuyết, Một Ethereum tập trung vào Rollup cũng giống như sự phân chia thực thi L1, và sau đó hỏi xem thế giới Ethereum L2 hiện tại thiếu sót ở điểm nào trong thực tế. Dưới đây là một số điểm:

• Địa chỉ cụ thể cho từng chuỗi: chuỗi (L1, Optimism, Arbitrum...) nên được bao gồm trong địa chỉ. Khi điều này được triển khai, luồng gửi qua L2 có thể được triển khai chỉ bằng cách đưa địa chỉ vào trường “gửi”, tại đó ví có thể tìm hiểu cách thức thực hiện gửi (bao gồm việc sử dụng giao thức cầu nối) ở nền tảng.
• Yêu cầu thanh toán cụ thể cho chuỗi: nên dễ dàng và chuẩn hóa để tạo một tin nhắn dạng “gửi cho tôi X token loại Y trên chuỗi Z”. Điều này có hai trường hợp sử dụng chính: (i) thanh toán, cho dù là từ người này sang người kia hoặc từ người sang dịch vụ thương mại, và (ii) ứng dụng yêu cầu quỹ, ví dụ như trên Polymarket.
• Giao dịch chéo chuỗi và thanh toán gas: nên có một giao thức mở chuẩn hóa để diễn đạt các hoạt động giao dịch chéo chuỗi như “Tôi đang gửi 1 ETH trên Optimism cho bất kỳ ai gửi cho tôi 0.9999 ETH trên Arbitrum”, và “Tôi đang gửi 0.0001 ETH trên Optimism cho bất kỳ ai bao gồm giao dịch này trên Arbitrum”.ERC-7683là một cố gắng ở phần trước, vàRIP-7755là một cố gắng trong việc sau này, tuy nhiên cả hai cũng rộng hơn chỉ là những trường hợp sử dụng cụ thể này.
• Khách hàng dễ dàng: người dùng nên có thể thực sự xác minh các chuỗi mà họ đang tương tác với, và không chỉ tin tưởng vào các nhà cung cấp RPC. A16z crypto’sHeliosđiều này cho Ethereum chính nó, nhưng chúng ta cần mở rộng tính không tin cậy này đến L2s.ERC-3668 (đọc CCIP)là một chiến lược để làm điều này.

Làm thế nào một máy khách nhẹ có thể cập nhật ý kiến của mình về chuỗi tiêu đề Ethereum. Khi bạn có chuỗi tiêu đề, bạn có thể sử dụng chứng minh Merkle để xác thực bất kỳ đối tượng trạng thái nào. Và khi bạn có các đối tượng trạng thái L1 đúng, bạn có thể sử dụng chứng minh Merkle (và có thể chữ ký, nếu bạn muốn kiểm tra trước xác nhận) để xác thực bất kỳ đối tượng trạng thái nào trên L2. Helios đã thực hiện phần trước đó. Mở rộng sang phần sau là một thách thức về tiêu chuẩn hóa.

• Ví lưu trữ: ngày nay, nếu bạn muốn cập nhật các khóa điều khiển ví hợp đồng thông minh của mình, bạn phải làm điều đó trên tất cả N chuỗi mà ví đó tồn tại. Ví lưu trữ là một kỹ thuật cho phép các khóa tồn tại tại một nơi (hoặc trên L1, hoặc sau này có thể trên L2) và sau đó được đọc từ bất kỳ L2 nào có bản sao của ví. Điều này có nghĩa là cập nhật chỉ cần xảy ra một lần. Để hiệu quả, ví lưu trữ yêu cầu L2 có một cách tiêu chuẩn để đọc L1 mà không tốn phí; có hai đề xuất cho điều này l à L1SLOAD và CUỘC GỌI TỪ XA.

Một biểu đồ được tạo hình về cách hoạt động của ví keystore.

• Các ý tưởng “cầu nối token chia sẻ” cấp tiến hơn: hãy tưởng tượng một thế giới nơi mà tất cả các L2 đều là rollup chứng minh tính hợp lệ, mà cam kết đến Ethereum mỗi khe. Ngay cả trong thế giới này, di chuyển tài sản từ một L2 sang một L2 khác “một cách tự nhiên” sẽ yêu cầu rút tiền và gửi tiền, điều này đòi hỏi phải trả một lượng gas L1 đáng kể. Một cách để giải quyết vấn đề này là tạo ra một rollup nhỏ chia sẻ, mà chức năng duy nhất của nó sẽ là duy trì các số dư của bao nhiêu token thuộc loại nào được sở hữu bởi L2 nào, và cho phép các số dư đó được cập nhật hàng loạt bởi một loạt các hoạt động gửi qua L2 khác nhau được khởi xướng bởi bất kỳ L2 nào. Điều này sẽ cho phép các chuyển giao qua L2 xảy ra mà không cần phải trả gas L1 cho mỗi chuyển giao, và không cần các kỹ thuật dựa trên nhà cung cấp thanh khoản như ERC-7683.
• Khả năng cơ bản đồng bộ: cho phép các cuộc gọi đồng bộ xảy ra giữa một L2 cụ thể và L1, hoặc giữa nhiều L2 khác nhau. Điều này có thể hữu ích trong việc cải thiện hiệu quả tài chính của các giao thức defi. Phần đầu có thể được thực hiện mà không cần bất kỳ phối hợp nào giữa các L2; phần sau sẽ đòi hỏi chuỗi chia sẻ. Dựa trên rollupstự động thân thiện với tất cả các kỹ thuật này.

Có những liên kết nào đến nghiên cứu hiện có?

• Đị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: @haichen/keystore"">https://hackmd.io/@haichen/keystore
• Helios: https://github.com/a16z/helios
• ERC-3668 (đôi khi được gọi là CCIP-read): https://eips.ethereum.org/EIPS/eip-3668
• Đề xuất về “xác nhận trước dựa trên (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
• REMOTESTATICCALL trong Optimism: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76
• AggLayer, bao gồm các ý tưởng cầu nối token chia sẻ: https://github.com/AggLayer

Còn gì phải làm, và có những sự đánh đổi nào?

Nhiều ví dụ trên đối mặt với những khúc mắc tiêu chuẩn hóa và tầng tiêu chuẩn hóa. Nếu tiêu chuẩn hóa quá sớm, bạn có nguy cơ cố định một giải pháp kém chất lượng. Nếu tiêu chuẩn hóa quá muộn, bạn có nguy cơ tạo ra sự phân mảnh không cần thiết. Trong một số trường hợp, có cả một giải pháp ngắn hạn có tính chất yếu hơn nhưng dễ triển khai, và một giải pháp dài hạn cuối cùng là “đúng đắn” nhưng sẽ mất khá nhiều năm để đạt được.

Một cách mà phần này độc đáo là những vấn đề này không chỉ là vấn đề kỹ thuật: chúng cũng là vấn đề xã hội (có lẽ thậm chí chủ yếu là vấn đề xã hội!). Chúng đòi hỏi L2s và ví và L1 phối hợp. Khả năng của chúng tôi để giải quyết vấn đề này một cách thành công là một bài kiểm tra cho khả năng của chúng tôi để đoàn kết như một cộng đồng.

Làm thế nào nó tương tác với các phần khác của lộ trình?

Hầu hết những đề xuất này là các cấu trúc ở tầng cao hơn, do đó không ảnh hưởng nhiều đến các xem xét của L1. Một ngoại lệ là việc xếp hàng chung, có tác động nặng nề đối với MEV.

Mở rộng thực thi trên L1

Vấn đề chúng ta đang giải quyết là gì?

Nếu L2 trở nên rất có khả năng mở rộng và thành công nhưng L1 vẫn chỉ có khả năng xử lý một lượng giao dịch rất thấp, có nhiều rủi ro đối với Ethereum có thể phát sinh:

1. Tình hình kinh tế của tài sản ETH trở nên nguy hiểm hơn, điều này ảnh hưởng đến tính bảo mật dài hạn của mạng lưới.
2. Nhiều L2 hưởng lợi từ việc chặt chẽ liên kết với một hệ sinh thái tài chính phát triển mạnh mẽ trên L1, và nếu hệ sinh thái này suy yếu mạnh, động lực để trở thành một L2 (thay vì là một L1 độc lập) cũng suy yếu
3. Các L2 sẽ mất rất nhiều thời gian trước khi có đợt chỉ bảo mật chính xác như L1.
4. Nếu một L2 thất bại (ví dụ, do một toán tử độc hại hoặc 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 họ. Do đó, L1 cần phải mạnh mẽ đủ để ít nhất là đôi khi thực sự xử lý một quá trình giảm tốc rất phức tạp và hỗn loạn của một L2.

Vì những lý do này, việc tiếp tục mở rộng L1 là rất quan trọng, và đảm bảo rằng nó có thể tiếp tục chứa đựng một số lượng người dùng ngày càng tăng.

Đó là gì và nó hoạt động như thế nào?

Cách dễ nhất để mở rộng là đơn giản tăng giới hạn gas. Tuy nhiên, điều này có nguy cơ tập trung L1, và do đó làm yếu đi tính chất quan trọng khác làm cho Ethereum L1 mạnh mẽ: tính xác thực của nó như một lớp cơ sở mạnh mẽ. Có một cuộc tranh luận đang diễn ra về mức độ tăng giới hạn gas đơn giản là bền vững, và điều này cũng thay đổi dựa trên những công nghệ khác được triển khai để làm cho các khối lớn hơn dễ dàng xác minh hơn (ví dụ: hết hạn lịch sử, không trạng thái, chứng minh tính hợp lệ của L1 EVM). Một điều quan trọng khác cần cải thiện là hiệu suất của phần mềm máy khách Ethereum, mà hiện nay được tối ưu hóa hơn nhiều so với năm 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 tăng tốc các công nghệ xác minh này.

Chiến lược mở rộng khác bao gồm việc xác định các tính năng cụ thể và loại tính toán có thể được làm rẻ hơn mà không gây hại đế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- một định dạng bytecode EVM mới thân thiện hơn với phân tích tĩnh, cho phép triển khai nhanh hơn. Bytecode EOF có thể được gán chi phí gas thấp hơn để xem xét những hiệu quả này.
• Định giá khí đa chiều- thiết lập các khoản phí cơ sở và giới hạn riêng cho tính toán, dữ liệu và lưu trữ có thể tăng khả năng trung bình của Ethereum L1 mà không cần tăng khả năng tối đa của nó (và do đó tạo ra các rủi ro bảo mật mới).
• Giảm chi phí gas của các mã opcode và biên dịch trước cụ thể - trong lịch sử, chúng tôi đã có một số vòngcủatănggaschi phíĐối với một số hoạt động đã được định giá thấp để tránh tấn công từ chối dịch vụ. Điều chúng ta đã ít làm, và có thể làm nhiều hơn, là giảm chi phí gas cho các hoạt động đã được định giá cao. Ví dụ, phép cộng rẻ hơn phép nhân, nhưng chi phí của các opcode ADD và MUL hiện tại là giống nhau. Chúng ta có thể làm cho việc ADD rẻ hơn, và thậm chí opcode đơn giản như PUSH còn rẻ hơn nữa.
• EVM-MAXvàSIMD: EVM-MAX (``tiện ích mở rộng số học moduler'') là một đề xuất cho phép tính toán số học moduler số lớ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 toán bởi các phép tính EVM-MAX chỉ có thể truy cập bởi các mã opcode EVM-MAX khác, trừ khi được xuất khẩu một cách cố ý; điều này cho phép lưu trữ các giá trị này một cách thoải mái hơn trong định dạng tối ưu hóa. SIMD ("single instruction multiple data") là một đề xuất cho phép thực thi một cách hiệu quả cùng một hướng dẫn trên một mảng các giá trị. Hai điều này cùng nhau có thể tạo ra một sức mạnhbộ xử lý phụ trợbên cạnh EVM có thể được sử dụng để triển khai các phép toán mật mã hiệu quả hơn nhiều. Điều này sẽ đặc biệt hữu ích cho các giao thức bảo mật, và cho các hệ thống chứng minh L2, vì vậy nó sẽ giúp cả việc mở rộng L1 và L2.

Những cải tiến này sẽ được thảo luận cụ thể hơn trong một bài viết trong tương lai về Splurge.

Cuối cùng, chiến lược thứ ba là native rollups (hoặc “enshrined rollups”): về cơ bản, tạo ra nhiều bản sao của EVM chạy song song, dẫn đến một mô hình tương đương với những gì rollups có thể cung cấp, nhưng tích hợp nhiều hơn vào giao thức.

Có những liên kết nào đến nghiên cứu hiện tại?

• Lộ trình mở rộng L1 của Ethereum của Polynya: https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ
• Định giá khí đ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
• Cuộn gốc:https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE
• Phỏng vấn với Max Resnick về giá trị của việc mở rộng L1: https://x.com/BanklessHQ/status/1831319419739361321
• Justin Drake về việc sử dụng SNARKs và native rollups để mở rộng:https://www.reddit.com/r/Ethereum/comments/1f81ntr/comment/llmfi28/

Còn gì cần làm, và phải đánh đổi những gì?

Có ba chiến lược cho việc mở rộng L1, có thể thực hiện độc lập hoặc song song:

• Cải thiện công nghệ (ví dụ: mã khách hàng, máy khách không lưu trạng thái, hết hạn lịch sử) để làm cho L1 dễ xác minh hơn, sau đó tăng giới hạn gas
• Làm cho các hoạt động cụ thể trở nên rẻ hơn, tăng khả năng trung bình mà không tăng nguy cơ trường hợp tồi tệ
• Rollups native (tức là "tạo N bản sao song song của EVM", tuy nhiên có thể mang lại cho các nhà phát triển rất nhiều linh hoạt trong các tham số của bản sao họ triển khai)

Đáng giá để hiểu rằng đây là những kỹ thuật khác nhau có những sự đánh đổi khác nhau. Ví dụ, native rollups có nhiều điểm yếu tương tự như tính kết hợp như các rollups thông thường: bạn không thể gửi một giao dịch duy nhất mà đồng bộ thực hiện các hoạt động trên nhiều rollups, giống như bạn có thể với hợp đồng trên cùng L1 (hoặc L2). Việc tăng giới hạn gas sẽ làm mất đi những 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 phần trăm người dùng chạy các nút xác minh và tăng solo stakers. Làm cho các hoạt động cụ thể trong EVM rẻ hơn, tùy thuộc vào cách thực hiện, có thể tăng độ phức tạp tổng EVM.

Một câu hỏi lớn mà bất kỳ lộ trình co giãn L1 nào cần phải trả lời là: tầm nhìn cuối cùng cho những gì thuộc về L1 và những gì thuộc về L2 là gì? Rõ ràng, việc đưa mọi thứ lên L1 là điều vô lý: các trường hợp sử dụng tiềm năng lên đến hàng nghìn giao dịch mỗi giây, và điều đó sẽ khiến L1 hoàn toàn không thể xác minh (trừ khi chúng ta đi theo con đường native rollup). Nhưng chúng ta cần một số nguyên tắc hướng dẫn, để chúng ta có thể đảm bảo rằng chúng ta không tạo ra tình huống mà chúng ta tăng giới hạn gas lên 10 lần, gây thiệt hại nặng nề cho tính phân quyền của Ethereum L1, và phát hiện rằng chúng ta chỉ đạt được một thế giới mà thay vì 99% hoạt động được chuyển sang L2, 90% hoạt động được chuyển sang L2, và do đó kết quả khác không nhiều, ngoại trừ việc mất mát không thể đảo ngược của một phần lớn những gì làm cho Ethereum L1 trở nên đặc biệt.

Một quan điểm đề xuất về "phân công lao động" giữa L1 và L2, nguồn.

Làm thế nào nó tương tác với các phần khác của lộ trình?

Đưa thêm người dùng vào L1 không chỉ áp dụng việc cải thiện quy mô, mà còn là các khía cạnh khác của L1. Điều này có nghĩa là MEV sẽ ở lại trên L1 nhiều hơn (thay vì trở thành một vấn đề chỉ dành cho L2), và do đó sẽ cần xử lý một cách rõ ràng hơn. Điều này tăng đáng kể giá trị của việc có thời gian slot nhanh trên L1. Và nó cũng phụ thuộc nhiều vào việc xác minh L1 ("the Verge") diễn ra tốt.

Tuyên bố từ chối trách nhiệm：

1. Bài viết này được tái bản từ [Vitalik Buterin], Tất cả bản quyền thuộc về tác giả gốc [Vitalik Buterin]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ với Học cửa và họ sẽ xử lý kịp thời.
2. Bảo Hiểm 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ỉ thuộc về tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. 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 dịch là không được phép.