Vitalik: Tại sao việc phá vỡ bộ ba bất khả thi lại khó khăn?

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, Người biên dịch: Deng Tong, Golden Finance

Đặc biệt cảm ơn Justin Drake, Francesco, Hsiao-wei Wang, @antanttc và Georgios Konstantopoulos

Lúc đầu, ether Có hai chiến lược mở rộng trong lộ trình của Fang. Một trong số đó 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 các chuỗi khối 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 hoạt động hoàn toàn mang lại lợi ích cho tính bảo mật của nó trong khi giữ hầu hết dữ liệu và tính toán khỏi 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 băng thông dữ liệu trên chuỗi đáng kể. May mắn thay, đến năm 2019, nghiên cứu sharding đã giải quyết được vấn đề xác thực “tính sẵn có của 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 quy mô 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 đảm nhận trách nhiệm giúp hệ sinh thái mở rộng Nhiệm vụ. Đâ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 cơ sở 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 một. 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ậyBây giờ chúng tôi được giao nhiệm vụ 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 giữ được những gì tạo nên sự mạnh mẽ và phân cấp độc đáo của Ethereum L1.

Surge: Mục tiêu chính

Hơn 100.000 TPS trên L1+L2

Duy trì tính phân cấp và tính mạnh mẽ của L1< /span >

Ít nhất một số L2 kế thừa đầy đủ các thuộc tính cốt lõi của Ethereum (không tin cậy, mở, chống kiểm duyệt)

< p>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 về khả năng mở rộng

Bộ ba bất khả thi về khả năng mở rộng là một ý tưởng được đề xuất vào năm 2017, xem xét ba khía cạnh của blockchain. Có sự căng thẳng giữa một số thuộc tính: phân cấp (cụ thể hơn: chi phí chạy một nút thấp), khả năng mở rộng (cụ thể hơn: xử lý khối lượng giao dịch lớn) và bảo mật (cụ thể hơn: nhu cầu kẻ tấn công phải xâm phạm. Phần lớn các nút trong toàn bộ mạng chỉ cần một lần giao dịch thất bại).

Điều đáng chú ý rằng, bộ ba bất khả thi không phải là một định lý, và bài 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 với phân cấp (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) các nút của bạn sẽ trở nên mạnh mẽ và chuỗi của bạn không được phân cấp. 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 thông minh nà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 các nút. Điều này luôn gây hiểu lầm và việc chạy một nút trong chuỗi như vậy sẽ luôn khó khăn hơn nhiều so với Ethereum. Bài viết 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 khách L1 không thể tự mở rộng quy mô Ethereum).

Tuy nhiên, sự kết hợp giữa lấy mẫu tính khả dụng của dữ liệu và SNARK sẽ giải quyết được bộ ba bất khả thi: nó cho phép khách hàng 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 phần dữ liệu nhỏ hơn đó và thực hiện số lượng phép tính nhỏ hơn nhiều. SNARK không đáng tin cậy. Việc 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 vi, nhưng nó vẫn giữ đặc tính cơ bản của các 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 giải 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 thông minh để chuyển trách nhiệm giám sát tính sẵn có của dữ liệu sang người dùng theo cách tương thích với động lực. Trở lại năm 2017-2019, khi tất cả những gì chúng ta cần để mở rộng quy mô đ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.

Tiến bộ hơn nữa trong việc lấy mẫu tính khả dụng của dữ liệu

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

Kể từ ngày 13 tháng 3 năm 2024, khi bản nâng cấp Dencun đi vào hoạt động, chuỗi khối Ethereum có 3 "đốm màu" xấp xỉ 125 kB mỗi khoảng thời gian 12 giây hoặc khoảng 375 kB dữ liệu mỗi khoảng thời gian Băng thông có sẵn. 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 là khoảng 180 byte, do đó TPS tối đa của các lần cuộn trên Ethereum là:

375000 / 12 / 180 = 173,6 TPS

Nếu Chúng tôi thêm dữ liệu lệnh gọi 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) và 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ẽ mang lại cho chúng tôi 463-926 TPS dữ liệu cuộc gọi.

Đâ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 khả năng mở rộng hơn. Mục tiêu trung hạn của chúng tôi là 16 MB mỗi ổ 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à hoạt động như thế nào?

PeerDAS là 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 bậc 4096 trên trường số nguyên tố 253 bit. Chúng tôi phát sóng "phần chia sẻ" của đa thức, trong đó mỗi phần chia sẻ 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 8192 đánh giá bất kỳ (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 khách hà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à ngoài ra, hãy hỏi các đồng nghiệp trong mạng p2p toàn cầu mạng để yêu cầu các đốm màu cần thiết trên các mạng con khác (những người sẽ lắng nghe trên các mạng con khác nhau). Một 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à các nút tham gia bằng chứng 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ề mặt lý thuyết, chúng tôi có thể mở rộng việc 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 (do đó, 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 tính khả dụng của dữ liệu chỉ tốn 16 mẫu trên mỗi nút * 128 blob * 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à các máy khách 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, thực hiện việc này 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. Các 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ức mở rộng đã hứa, vì vậy sơ đồ này về cơ bản là 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.

Mối liên hệ với nghiên cứu hiện tại là gì?

Bài viết gốc giới thiệu về tính khả dụng của dữ liệu (2018): https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding

< p style="text-align: left;">Bài viết tiếp theo: https://arxiv.org/abs/1809.09044

Bài đăng giải thích cho DAS, Paradigm: https:// www.paradigm.xyz/2022/08/das

Tính khả dụng 2D được KZG hứa hẹn: https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081

< p style="text-align: left;">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

< p style="text-align: left;">SubnetDAS trên ethresear.ch: https: // ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169

Sự khác biệt tinh tế về khả năng phục hồi trong lấy mẫu 2D: https://ethresear.ch/t/nuances-of-data- recoveryability-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ư an toàn quy tắc lựa chọn phân nhánh.

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 điều đó đặc tính an toàn. Chúng tôi cũng hy vọng cuối cùng sẽ chuyển từ KZG sang các lựa chọn thay thế có khả năng kháng lượng tử và 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 ứ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 ra 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ộ blob

Về lâu dài, tôi nghĩ con đường thực tế là: kiểu

• Công cụ DAS 2D lý tưởng;

• Bám sát DAS 1D, hy sinh tính đơn giản và mạnh mẽ Hiệu suất băng thông mẫu và chấp nhận giới hạn dữ liệu thấp hơn;

• (Trục cứng) Từ bỏ DA và hoàn toàn sử dụng 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ể xem xét 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 quy mô thực thi trực tiếp trên L1. Điều này là do nếu L1 xử lý một số lượng lớn TPS thì khối L1 sẽ trở nên rất lớn , khách hàng sẽ cần một cách 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ợ tổng hợp (ZK-EVM và DAS) và L1

Nó phù hợp như thế nào với lộ trình khác. tương tác một phần?

Nhu cầu về DAS 2D sẽ giảm 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 DAS cũng đặt ra những thách thức đối với khối phân tán. các giao thức và cơ chế xây dựng: 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 đề xuất danh sách đưa vào và cơ chế lựa chọn nhánh xung quanh nó. >

Nén dữ liệu

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

Mọi giao dịch trong Rollup Cả hai đều chiếm nhiều không gian dữ liệu trên chuỗi: chuyển khoản ERC20 chiếm khoảng 180 byte, điều này giới hạn khả năng mở rộng của giao thức lớp 2 ở mức 16 MB mỗi khe.

16000000/12/180 = 7407 TPS

Điều gì sẽ xảy ra nếu, ngoài việc giải quyết vấn đề. tử số, chúng ta cũng có thể giải mẫu số và làm cho mỗi giao dịch trong tổng số chiếm ít byte hơn trên chuỗi, phải làm gì?

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

Tôi nghĩ 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 lợi đơn giản nhất là nén 0 byte: thay thế mỗi chuỗi dài gồm 0 byte 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:

• Chữ ký tổng hợp< - Chúng ta chuyển từ chữ ký ECDSA sang chữ ký BLS, có tính chất kết hợp nhiều chữ ký lại với nhau thành một chữ ký duy nhất chứng minh tính hợp lệ của tất 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 môi trường 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 tới địa chỉ địa điểm lịch sử. Điều này là cần thiết để đạt được lợi ích tối đa, mặc dù sẽ cần 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ỳ chỉnh tuần tự 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. Phí 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.

Mối liên hệ với nghiên cứu hiện tại là gì?

Khám phá từ Sequence.xyz: https://sequence. /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-optimizooors

Một chiến lược khác - dựa trên tính hiệu quả Bản tổng hợp đã được chứng minh (hay còn gọi là Bản tổng hợp ZK) công bố 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- -l2-data dấu chân trên -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 và cần phải đánh đổi những gì?

Việc chính còn lại phải làm là thực hiện kế hoạch trên. Sự cân bằng chính là:

• Việc chuyển sang chữ ký BLS đòi hỏi 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 lược đồ 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 khách.

• Việc xuất bản các khác biệt trạng thái cho chuỗi thay vì giao dịch làm giảm khả năng kiểm tra và ngăn cản nhiều phần mềm (chẳng hạn như trình khám phá khối) 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ể tăng tốc độ triển khai trên L2.

Plasma tổng quát

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

Ngay cả với các đốm màu 16 MB và khả năng 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. Điều này đặc biệt đúng nếu chúng ta bắt đầu nghĩ đến quyền riêng tư. Có thể giảm khả năng mở rộng từ 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à hoạt động như thế nào?

Plasma là một giải pháp mở rộng quy mô 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, đưa toàn bộ khối vào chuỗ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 được 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 quay 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 trên chuỗi có thể xét xử chính xác tài sản đó thuộc về ai.



Sơ đồ 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 trước 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ở rộng quy mô 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 phải chờ thời gian thử thách kéo dài một tuần.




Một cách để tạo chuỗi EVM Plasma (không phải chỉ một Phương thức): Sử dụng ZK-SNARK để xây dựng cây UTXO song song phản ánh những thay đổi về 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 điều 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 của mình (ví dụ: thậm chí chỉ các mã thông báo 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 có khả năng mở rộng siêu quy mô, đó là xác thực.

Một loại cấu trúc khác là cấu trúc Plasma/rollups lai, 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 Khả năng 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.

Mối liên hệ 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

Những điều khác cần phải làm và sự đánh đổi là 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 mục đích đạ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 so với các bản tổng hợp cần được giải quyết trực tiếp thông qua nghiên cứu và xây dựng các 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ó "dựa vào" 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 hoàn thiện

Chúng ta muốn giải quyết những vấn đề gì?

Ngày nay, hầu hết các tập hợp không 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) theo văn bản này, Lạc quan 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 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à hoạt động như thế nào?

Đầu tiên, chúng ta hãy xem lại hệ thống “sân khấu” được giới thiệu ban đầu trong 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 số 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à hơn 26%) phải nằm ngoài các công ty lớn 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 bản 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 bản nâng cấp đi vào hoạt động.

• 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 cách chính để thực hiện việc này:

• Xác minh chính thức :< /strong>Chúng tôi 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.

• Nhiều người chứng thực: Tạo ra nhiều hệ thống chứng thực và đầu tư tiền vào các hệ thống chứng thực và ủy ban bảo mật này (và/hoặc các nhóm nhỏ khác với các giả định về độ tin cậy) 2 -of-3 (hoặc lớn hơn) multisig giữa các công cụ 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 số họ và không thể đơn phương áp đặt câu trả lời của mình.



Sơ đồ 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.

Mối liên hệ 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

Bản demo về ý tưởng của nhiều người chứng minh (2022): https://www.youtube.com/watch?v=6hfVzCWT6YI

Taiko dự định sử dụng nhiều bằng chứng: https://docs.taiko.xyz/core- concept/multi -proofs/

Cần phải làm gì nữa và cần cân nhắc điều gì?

Để xác minh chính thức thì 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 cho 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 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 dành cho nhiều người chứng minh. 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ó nhiều cách để làm cho 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 phải 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 hoạt động sang L2 giúp giảm áp lực MEV lên L1.

Cải thiện khả năng tương tác Cross-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 gặp khó khăn trong việc điều hướng. Ngoài ra, các cách tiếp cận đơ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 khách RPC, v.v. Nếu chúng ta nghiêm túc về ý tưở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 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) trên L2 UX - mặc dù đây không phải lỗi của Polymarket, nhưng 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 hệ sinh thái Ethereum hoạt động tốt, việc gửi mã thông báo từ L1 đến L2 hoặc từ L2 này sang L2 khác sẽ giống như gửi mã thông báo trong cùng một L1.

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

Có nhiều loại cải tiến về khả năng tương tác xuyên L2. Nói chung, cách đặ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 của 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ể của 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 theo chuỗi cụ thể: Việc tạo thông báo có dạng "Gửi cho tôi X token 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 chéo 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 về Lạc quan "Gửi đến người đã gửi 0,9999 ETH trên Arbitrum" và "Tôi đã gửi 0,0001 ETH theo Lạc quan cho bất kỳ ai đã thực hiện giao dịch này trên Arbitrum" ERC-7683 là một nỗ lực trước đây, trong khi RIP-7755 là một nỗ lực nhằm sau , mặc dù cả hai đều chung chung hơn các trường hợp sử dụng cụ thể này

• Ứng dụng khách nhẹ: Người dùng có thể thực sự xác minh chuỗi mà họ đang tương tác. , không chỉ. Chỉ cần tin tưởng vào nhà cung cấp RPC. Tiền điện tử A16z thực hiện điều này cho chính Ethereum, nhưng chúng tôi cần mở rộng sự không tin cậy này sang L2 (CCIP-read) là một chiến lược để đạt được điều này. /li>



Cách một ứng dụng khách nhẹ cập nhật chế độ xem của chuỗi tiêu đề Ethereum Khi bạn có chuỗi tiêu đề Bạn có thể sử dụng bằng chứng Merkle để xác minh bất kỳ 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ể cả 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 <. em>Helios  Mở rộng sang cái sau 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 khóa kiểm soát ví hợp đồng thông minh, bạn phải thực hiện việc này trên tất cả N chuỗi mà ví đó đang hoạt động. Ví keystore là công nghệ cho phép sử dụng 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 đọc từ bất kỳ L2 nào có bản sao của ví. Việc này 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ó một cách thức được tiêu chuẩn hóa. để đọc L1 miễn phí; hai gợi ý cho việc này là L1SLOAD và REMOESTATICCALL.



Sơ đồ cách điệu về cách hoạt động của ví Keystore.

• Một ý tưởng "cầu nối mã thông báo chia sẻ" cấp tiến hơn :Hãy tưởng tượng một thế giới trong đó tất cả L2 đều là 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 di chuyển tài sản "cục bộ" từ L2 này sang L2 khác yêu cầu rút tiền và gửi tiền, đòi hỏi phải trả nhiều gas L1. Một cách để 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 mã thông báo và cho phép các số dư này được cập nhật chung thông qua một loạt 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 mỗi lần chuyển và không yêu cầu 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.

Mối liên hệ với nghiên cứu hiện tại là gì?

Địa chỉ dành riêng cho chuỗi: ERC-3770: https: / /eips.ethereum.org/EIPS/eip-3770

ERC-7683: https://eips.ethereum.org/EIPS/eip-7683

RIP-7755: < a href="https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md">https://github.com/wilsoncusack/RIPs/blob/ cross -l2-call-standard/RIP/rip-7755.md

Thiết kế ví kho khóa cuộn: 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< /p>

Đề xuất "(được chia sẻ) dựa trên xác nhận trước" của Justin Drake: https://ethresear.ch/t/based-preconfirmations/17353

L1SLOAD (RIP-7728):   "https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388">https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388< /a>< /p>

Các cuộc gọi từ xa với tinh thần lạc quan: https:/ /github.com/ethereum-optimism/ecosystem-contributions/issues/76

AggLayer, bao gồm cầu nối mã thông báo được chia sẻ Suy nghĩ: 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 là 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 sẽ gặp rủi ro về 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à những nhiệm vụ này không chỉ là vấn đề kỹ thuật: chúng còn (có lẽ hầu hết!) là 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 đó không có nhiều tác động đến việc cân nhắc L1. Một ngoại lệ là việc đặt hàng chung, điều này có tác động lớn đến MEV.

Mở rộng việc 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ó khả năng 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 đối với 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 cơ trở thành L2 (chứ không phải L1 độc lập) sẽ yếu đi.

• Sẽ phải mất một thời gian dài nữa L2 mới có được những đảm bảo an ninh giống hệt như L1.

• Nếu L2 không thành công (ví dụ do hành độ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 để lấy lại 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 số lượng mục đích sử dụng ngày càng tăng là rất có giá trị.

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

Cách dễ nhất để mở rộng quy mô là chỉ cần tăng giới hạn Gas. Tuy nhiên, điều này có nguy cơ 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 khách 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 quy mô khác liên quan đến việc xác định các chức năng và loại điện 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 mạng. Ví dụ về điều này bao gồm:

• EOF - 1 A đị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ơ sở riêng biệt cho tính toán, dữ liệu và lưu trữ có thể tăng công suất trung bình của Ethereum L1 mà không làm 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 cho các mã hoạt động và biên dịch trước cụ thể - Trong lịch sử, chúng tôi đã thực hiện một số lần tăng chi phí gas vòng để 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 ("Phần mở rộng số học mô-đun") là một đề xuất nhằm cho phép toán học số học quy mô lớn bản địa hiệu quả hơn Toán học mô-đun 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 mã hóa 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ẽ hỗ trợ mở rộng quy mô 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 sau 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 là 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 còn hơn thế nữa được tích hợp nguyên bản vào giao thức.

Mối liên hệ 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

Giá gas đa chiều: https://vitalik.eth.limo/general/2024/05/09/multidim.html

EIP-7706:https://eips.ethereum.org/EIPS/eip-7706< /a>

EOF:https://evmobjectformat.org/< /p>

EVM-MAX:https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168

SIMD : https://eips.ethereum.org/EIPS/eip-616

< p style= "text-align: left;">Tóm tắt gốc:https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgog k6io1GE < /a>

Phỏng vấn Max Resnick về giá trị của việc gia hạn L1: https : //x.com/BanklessHQ/status/1831319419739361321

Justin Drake về việc mở rộng quy mô bằng SNARK và tập hợp gốc: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

Còn cần làm gì nữa và cần cân nhắc 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 khách, máy khách 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í của các hoạt động cụ thể, trong 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ù nó có thể hữu ích cho các nhà phát triển để triển khai các bản sao mang lại nhiều tính linh hoạt về mặt tham số)

Cần hiểu rằng đây là những kỹ thuật khác nhau với sự đánh đổi khác nhau. Ví dụ: các bản tổng hợp gốc có nhiều điểm yếu về khả năng kết hợp giống như các bản tổng hợp thông thường: 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àm mất đ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 các 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.

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à: Tầm nhìn 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: các trường hợp sử dụng tiềm năng có 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 đến tính phân cấp 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% như trước đây. hoạt động diễn ra trên L2, 90% hoạt động diễn ra 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.



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

Nó phù hợp như thế nào với lộ trình Các phần khác của sự tương tác?

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 việc xác nhận L1 ("The Verge") diễn ra suôn sẻ.