Tác giả: Ye Zhang@Scroll

Cảm ơn Vitalik Buterin, Barry Whitehat, Chih-Cheng Liang, Kobi Gurkan và Georgios Konstantopoulos vì những đánh giá và hiểu biết sâu sắc của họ.

quá lâu

Chúng tôi tin rằng zk-Rollup sẽ trở thành một "điểm hấp dẫn" - lợi thế về chi phí và tính bảo mật cực cao của nó sẽ khiến nhiều giải pháp khả năng mở rộng Lớp 2 trở nên mờ nhạt khi so sánh. Tuy nhiên, các triển khai zk-Rollup hiện tại đều dành riêng cho ứng dụng, do đó, rất khó để chúng tôi xây dựng một dApp có mục đích chung có thể kết hợp trong một zk-Rollup nhất định và không thể di chuyển các ứng dụng hiện có. Chúng tôi giới thiệu zkEVM để tạo bằng chứng không có kiến ​​thức để xác minh EVM chung. Bằng cách này, chúng tôi có thể xây dựng một zk-Rollup hoàn toàn tương thích với EVM, để các ứng dụng Ethereum hiện tại có thể dễ dàng di chuyển sang zk-Rollup này.

lý lịch

lý lịch

zk-Rollup được công nhận là giải pháp mở rộng Ethereum tốt nhất. Nó không chỉ có thể so sánh với Ethereum Lớp 1 về mặt bảo mật mà còn dẫn đầu các giải pháp Lớp 2 về tốc độ hoàn tất giao dịch (bấm vào đây để xem phân tích so sánh chi tiết (văn bản gốc, bản dịch)).

Trong trung và dài hạn, với sự phát triển không ngừng của công nghệ ZK-SNARK, zk-rollup sẽ dẫn đầu trong mọi tình huống ứng dụng. ——Vitalik Buterin

Nguyên tắc cơ bản của zk-Rollup là đóng gói một số lượng lớn giao dịch vào một khối Rollup và tạo bằng chứng ngắn gọn cho khối đó ngoài chuỗi. Các hợp đồng thông minh trên Lớp 1 sau đó chỉ cần xác minh bằng chứng này để áp dụng trực tiếp trạng thái mới mà không cần phải thực hiện lại các giao dịch này. Điều này dẫn đến tiết kiệm gas ở mức độ lớn, vì chi phí xác minh bằng chứng thấp hơn nhiều so với chi phí tính toán của việc thực hiện lại. Một lợi ích khác là không gian lưu trữ có thể được tiết kiệm thông qua nén dữ liệu (nghĩa là chỉ một lượng dữ liệu tối thiểu được lưu trữ trên chuỗi để xác thực).

Mặc dù zk-Rollup an toàn và hiệu quả nhưng ứng dụng của nó vẫn bị giới hạn trong thanh toán và hoán đổi. Các dApp có mục đích chung rất khó xây dựng vì hai lý do chính:

• Đầu tiên, nếu bạn muốn phát triển một dApp trong zk-Rollup, bạn cần sử dụng một ngôn ngữ đặc biệt (ví dụ: R1CS) để viết logic của tất cả các hợp đồng thông minh của bạn. Ngôn ngữ này có cú pháp phức tạp và yêu cầu người dùng phải thành thạo các bằng chứng không có kiến ​​thức.

• Thứ hai, các triển khai zk-Rollup hiện tại không hỗ trợ khả năng kết hợp1. Do đó, trên Lớp 2, các ứng dụng zk-Rollup khác nhau không thể tương tác với nhau, điều này làm hỏng nghiêm trọng khả năng kết hợp của các ứng dụng DeFi.

Tóm lại, zk-Rollup hiện không thân thiện với nhà phát triển và có chức năng hạn chế. Đây là vấn đề lớn nhất mà chúng tôi muốn giải quyết. Chúng tôi muốn cung cấp trải nghiệm tốt nhất cho nhà phát triển bằng cách hỗ trợ trực tiếp xác minh EVM gốc và hỗ trợ khả năng kết hợp trên Lớp 2 để các ứng dụng Ethereum hiện có có thể được di chuyển nguyên vẹn sang zk-Rollup.

Xây dựng Universal dApps trong zk-Rollup

Chúng tôi có thể xây dựng các dApp có mục đích chung trong zk-Rollup theo hai cách:

• Một là xây dựng các mạch dành riêng cho ứng dụng (“ASIC”) cho các dApp khác nhau.

• Cách khác là xây dựng các mạch "EVM" có mục đích chung để thực hiện các hợp đồng thông minh.

"Mạch" đề cập đến biểu diễn chương trình được sử dụng trong bằng chứng không kiến ​​thức. Ví dụ, nếu bạn muốn chứng minh rằng hash(x) = y, bạn cần viết lại hàm băm dưới dạng mạch. Dạng mạch chỉ hỗ trợ biểu diễn rất hạn chế (tức là R1CS chỉ hỗ trợ cộng và nhân). Do đó, việc viết chương trình bằng ngôn ngữ mạch là rất khó - bạn chỉ có thể sử dụng phép cộng và phép nhân để xây dựng tất cả logic chương trình (bao gồm if other, vòng lặp, v.v.).

Phương pháp đầu tiên yêu cầu các nhà phát triển thiết kế các mạch "ASIC" chuyên dụng cho các dApp khác nhau. Đây là cách truyền thống nhất để sử dụng bằng chứng không kiến ​​thức. Thiết kế mạch tùy chỉnh giúp giảm chi phí cho các dApp riêng lẻ. Tuy nhiên, điều này cũng đặt ra một vấn đề về khả năng kết hợp, vì các mạch là "tĩnh" và sự phụ thuộc nhiều vào kiến ​​thức thiết kế mạch dẫn đến trải nghiệm của nhà phát triển kém2.

Phương pháp thứ hai không yêu cầu bất kỳ thiết kế đặc biệt nào, cũng như không yêu cầu nhà phát triển phải có kiến ​​thức chuyên môn vững vàng. Khái niệm cơ bản đằng sau loại bằng chứng dựa trên máy này là bất kỳ chương trình nào cuối cùng cũng sẽ chạy trên CPU. Do đó, chúng ta chỉ cần xây dựng một mạch CPU đa năng để xác minh các hoạt động của CPU ở mức độ thấp. Sau đó, chúng tôi có thể sử dụng mạch CPU này để xác minh bất kỳ việc thực hiện chương trình nào. Đối với kịch bản ứng dụng của bài viết này, chương trình đề cập đến hợp đồng thông minh và CPU đề cập đến EVM. Tuy nhiên, phương pháp này đã không được áp dụng rộng rãi trong vài năm qua do chi phí cao. Ví dụ: ngay cả khi bạn chỉ muốn chứng minh rằng kết quả của phép cộng trong một thao tác nào đó là đúng, thì bạn vẫn cần phải chịu chi phí cho toàn bộ mạch EVM. Nếu bạn có hàng nghìn hoạt động trong quá trình theo dõi thực thi của mình, thì phương châm sẽ trả gấp 1000 lần chi phí cho mạch EVM3.

Gần đây, rất nhiều nghiên cứu đã được dành cho việc tối ưu hóa ZKP bằng hai phương pháp này, bao gồm (i) đề xuất một hàm băm Poseidon nguyên thủy thân thiện với ZKP mới (hàm băm Poseidon hiệu quả hơn 100 lần trong các mạch so với SHA256); (ii) tiếp tục cải tiến trong hiệu quả của các máy ảo có thể kiểm chứng cho mục đích chung, như TinyRAM; (iii) ngày càng có nhiều kỹ thuật tối ưu hóa cho mục đích chung, chẳng hạn như Plookup và các thư viện mật mã chạy nhanh hơn.

Trong bài viết trước của chúng tôi, chúng tôi đã đề xuất thiết kế các mạch "ASIC" cho mỗi dApp và để chúng giao tiếp thông qua các cam kết mã hóa. Tuy nhiên, dựa trên phản hồi của cộng đồng, chúng tôi đã thay đổi trọng tâm nghiên cứu của mình và sẽ tập trung vào việc sử dụng phương pháp thứ hai để xây dựng các mạch EVM có mục đích chung (cái gọi là "zkEVM"). zkEVM sẽ mang lại trải nghiệm phát triển chính xác giống như Lớp 1. Thay vì để lại sự phức tạp trong thiết kế cho nhà phát triển, chúng tôi thay thế nó bằng một thiết kế mạch EVM tùy chỉnh để giải quyết các vấn đề về hiệu quả.

Thách thức thiết kế của zkEVM

zkEVM khó xây dựng. Mặc dù trực giác này đã rõ ràng trong nhiều năm, nhưng vẫn chưa có ai thành công trong việc xây dựng một mạch EVM riêng. Không giống như TinyRAM, zkEVM khó thiết kế và triển khai hơn vì những lý do sau:

• Đầu tiên, EVM hỗ trợ hạn chế cho các đường cong elip. Hiện tại, EVM chỉ hỗ trợ ghép nối BN254. EVM khó triển khai đệ quy có thể chứng minh được vì chúng không hỗ trợ trực tiếp các đường cong elip tuần hoàn. Trong thiết lập này, chúng tôi cũng khó sử dụng các giao thức độc quyền khác. Thuật toán xác minh phải thân thiện với EVM.

• Thứ hai, kích thước từ của EVM là 256 bit. EVM chạy trên số nguyên 256 bit (giống như hầu hết các máy ảo phổ biến chạy trên số nguyên 32-64 bit) và bằng chứng không kiến ​​thức "tự nhiên" chạy trên các trường nguyên tố. Thực hiện "số học miền không khớp" trong một mạch yêu cầu bằng chứng phạm vi, do đó sẽ thêm khoảng 100 ràng buộc cho mỗi hoạt động EVM. Điều này làm tăng kích thước mạch EVM lên hai bậc độ lớn.

• Thứ ba, EVM có nhiều opcode đặc biệt. Không giống như các máy ảo truyền thống, EVM có nhiều mã lệnh đặc biệt, chẳng hạn như CALL và các loại lỗi liên quan đến môi trường thực thi và gas. Điều này sẽ mang lại những thách thức mới cho thiết kế mạch.

• Thứ tư, EVM là một máy ảo dựa trên ngăn xếp. Kiến trúc SyncVM (zksync) và Cario (starkware) xác định IR/AIR của riêng chúng trong mô hình dựa trên đăng ký. Họ đã xây dựng một trình biên dịch chuyên dụng để biên dịch mã hợp đồng thông minh thành một IR thân thiện với bằng chứng không có kiến ​​thức mới. Phương pháp này tương thích với ngôn ngữ, không tương thích với EVM gốc. Việc chứng minh một mô hình dựa trên ngăn xếp hay hỗ trợ trực tiếp các chuỗi công cụ gốc đều trở nên khó khăn hơn.

• Thứ năm, cách bố trí lưu trữ của Ethereum mang lại chi phí cao. Bố cục lưu trữ Ethereum chủ yếu dựa vào Keccak và MPT4 khổng lồ. Cả hai đều không thân thiện với bằng chứng kiến ​​​​thức và phải chịu chi phí bằng chứng cao. Ví dụ: hàm băm Keccak có kích thước mạch gấp 1000 lần hàm băm Poseidon. Tuy nhiên, nếu bạn thay thế hàm băm Keccak bằng một hàm băm khác, nó sẽ gây ra một số vấn đề tương thích với cơ sở hạ tầng Ethereum hiện có.

• Thứ sáu, bằng chứng dựa trên máy móc đi kèm với chi phí cao. Ngay cả khi bạn có thể xử lý tất cả những điều trên, bạn vẫn cần tìm một cách hiệu quả để kết hợp chúng để có được một mạch EVM hoàn chỉnh. Như tôi đã đề cập trong phần trước, ngay cả một opcode đơn giản như add cũng có thể khiến bạn mất toàn bộ mạch EVM.

Tại sao zkEVM có thể có ngày hôm nay

Nhờ những tiến bộ đáng kể mà các nhà nghiên cứu đã đạt được, ngày càng có nhiều vấn đề về hiệu quả được giải quyết trong hai năm qua và chi phí chứng minh của zkEVM cuối cùng không còn là trở ngại nữa! Tiến bộ kỹ thuật chính được phản ánh trong các khía cạnh sau:

• Sử dụng các cam kết đa thức. Hầu hết các giao thức bằng chứng zero-knowledge ngắn gọn trong vài năm qua đã sử dụng R1CS, với các truy vấn PCP được mã hóa thành các thiết lập đáng tin cậy dành riêng cho ứng dụng. Điều này có xu hướng làm tăng kích thước của mạch, khiến nhiều tối ưu hóa tùy chỉnh không thể thực hiện được vì mỗi ràng buộc phải ở mức 2 (ghép song tuyến tính chỉ cho phép một phép tính nhân theo cấp số nhân). Với lược đồ cam kết đa thức, bạn có thể tăng các ràng buộc của mình đối với bất kỳ đơn đặt hàng nào thông qua thiết lập chung hoặc thậm chí là thiết lập minh bạch, giúp tăng đáng kể tính linh hoạt của lựa chọn phụ trợ.

• Sự xuất hiện của bảng tra cứu thông số và widget tùy chỉnh. Một tối ưu hóa quan trọng khác là việc sử dụng các bảng tra cứu. Tối ưu hóa này lần đầu tiên được đề xuất trong Arya và sau đó được triển khai trong Plookup. Đối với các nguyên hàm không thân thiện với bằng chứng không có kiến ​​thức (nghĩa là các phép toán bitwise như AND và XOR), các bảng tra cứu có thể tiết kiệm rất nhiều công việc. Các tiện ích tùy chỉnh có thể triển khai các ràng buộc cấp cao một cách hiệu quả. TurboPlonk và UltraPlonk xác định cú pháp chương trình tao nhã giúp giảm bớt khó khăn khi sử dụng bảng tra cứu và xác định các tiện ích tùy chỉnh. Điều này giúp ích rất nhiều trong việc giảm giá thành của mạch EVM.

• Tính khả thi của chứng minh đệ quy ngày càng cao. Trước đây, chứng minh đệ quy rất tốn kém vì chúng dựa vào các đường cong elip tròn thân thiện với cặp ghép đặc biệt (nghĩa là các cấu trúc dựa trên đường cong MNT). Điều này phát sinh một chi phí tính toán cao. Tuy nhiên, ngày càng có nhiều kỹ thuật cho phép chứng minh đệ quy mà không làm giảm hiệu quả. Ví dụ: Halo không yêu cầu các đường cong thân thiện với cặp và cũng có thể sử dụng tham số sản phẩm bên trong đặc biệt để phân bổ chi phí đệ quy. Aztec chứng minh các bằng chứng có thể được tổng hợp trực tiếp từ các giao thức hiện có (bảng tra cứu có thể giảm chi phí cho các hoạt động của miền không bản địa, do đó giảm kích thước của các mạch xác minh). Kích thước mạch tương tự bây giờ có thể đạt được nhiều chức năng hơn.

• Tăng tốc phần cứng đang cải thiện hiệu quả bằng chứng. Theo hiểu biết tốt nhất của chúng tôi, chúng tôi đã xây dựng bộ tăng tốc GPU và ASIC/FPGA nhanh nhất cho các chương trình kiểm chứng. Bài báo của chúng tôi về quy trình chứng minh ASIC đã được ISCA, hội nghị học thuật máy tính hàng đầu, chấp nhận trong năm nay. Trình chứng minh GPU của chúng tôi nhanh hơn khoảng 5 đến 10 lần so với triển khai của Filecoin, điều này có thể cải thiện đáng kể hiệu quả tính toán của trình chứng minh.

zkEVM hoạt động và xây dựng như thế nào?

Ngoài trực giác mạnh mẽ và cải tiến kỹ thuật, chúng tôi phải tìm ra những gì chúng tôi cần chứng minh và hình thành một kiến ​​trúc cụ thể hơn. Chi tiết kỹ thuật và phân tích so sánh sẽ được dành cho các bài viết trong tương lai. Trong bài viết này, chúng tôi sẽ giới thiệu toàn bộ quy trình làm việc và một số khái niệm cốt lõi.

Quy trình làm việc cho nhà phát triển và người dùng

Các nhà phát triển có thể sử dụng các ngôn ngữ tương thích với EVM để thực hiện các hợp đồng thông minh và triển khai các mã byte được biên dịch trên Scroll. Sau đó, người dùng có thể gửi các giao dịch để tương tác với các hợp đồng thông minh đã triển khai. Người dùng và nhà phát triển sẽ có trải nghiệm giống như trên Lớp 1. Tuy nhiên, phí gas sẽ thấp hơn đáng kể và các giao dịch sẽ được xác nhận trước ngay lập tức trên Scroll (việc rút tiền sẽ chỉ mất vài phút để hoàn tất).

Quy trình làm việc của zkEVM

Mặc dù quy trình làm việc bên ngoài vẫn giữ nguyên, nhưng quá trình xử lý cơ bản của Lớp 1 và Lớp 2 hoàn toàn khác nhau:

• Lớp 1 dựa vào việc thực hiện lại các hợp đồng thông minh.
• Lớp 2 dựa vào bằng chứng về tính hợp lệ của mạch zkEVM

Hãy giải thích chi tiết các giao dịch trên Lớp 1 và Lớp 2 khác nhau như thế nào.

Trên Lớp 1, mã byte của các hợp đồng thông minh đã triển khai được lưu trữ trong bộ lưu trữ Ethereum (các mục lưu trữ). Các giao dịch sẽ được lan truyền trong một mạng ngang hàng. Đối với mỗi giao dịch, mỗi nút đầy đủ cần tải mã byte tương ứng và thực thi nó trên EVM để có được trạng thái giống nhau (giao dịch sẽ được sử dụng làm dữ liệu đầu vào).

Trên Lớp 2, mã byte cũng được lưu trữ trong mục lưu trữ và người dùng thao tác theo cách tương tự. Các giao dịch được gửi ngoại tuyến đến một nút zkEVM tập trung. Sau đó, thay vì chỉ thực thi mã byte, zkEVM sẽ tạo ra một bằng chứng ngắn gọn rằng trạng thái đã được cập nhật chính xác sau giao dịch. Cuối cùng, hợp đồng Lớp 1 sẽ xác minh bằng chứng và cập nhật trạng thái mà không cần thực hiện lại giao dịch.

Hãy đi sâu vào quá trình thực thi và xem zkEVM cuối cùng cần chứng minh điều gì. Trong quá trình thực thi gốc, EVM sẽ tải mã byte và thực thi lần lượt các opcode trong mã byte từ đầu. Mỗi opcode có thể được xem như thực hiện ba bước sau: (i) đọc các phần tử từ ngăn xếp (stack), bộ nhớ hoặc mục lưu trữ; (ii) thực hiện tính toán dựa trên các phần tử này; (iii) ghi kết quả vào ngăn xếp, bộ nhớ, hoặc mục lưu trữ5. Ví dụ: opcode thêm cần đọc hai phần tử từ ngăn xếp, thêm chúng và ghi kết quả vào ngăn xếp.

Do đó, rõ ràng là bằng chứng của zkEVM cần bao gồm các khía cạnh sau (tương ứng với luồng thực thi):

• Mã byte được tải chính xác từ bộ lưu trữ liên tục (bạn đang chạy đúng opcode được tải từ một địa chỉ)
• Các mã lệnh trong mã byte luôn được thực thi từng cái một (mã byte được thực thi tuần tự, không có mã lệnh nào bị bỏ sót hoặc bỏ qua)
• Mỗi opcode thực thi chính xác (ba sub-op trong mỗi opcode thực thi chính xác, R/W + tính toán)

Điểm nổi bật về thiết kế zkEVM

Khi thiết kế kiến ​​trúc cho zkEVM, chúng ta cần thực hiện các biện pháp để đáp ứng ba yêu cầu trên tương ứng.

1. Chúng ta cần thiết kế một mạch cho bộ tích lũy mật mã.

Điều này hoạt động như một "bộ nhớ có thể kiểm chứng", chúng tôi cần một số loại công nghệ để chứng minh rằng quá trình đọc là chính xác. Bộ tích lũy mật mã có thể làm điều này hiệu quả hơn6. Hãy lấy cây Merkle làm ví dụ. Các mã byte đã triển khai được lưu trữ dưới dạng các nút lá trên cây Merkle. Sau đó, người xác minh có thể sử dụng bằng chứng ngắn gọn để xác minh rằng mã byte này đã được tải chính xác từ một địa chỉ (nghĩa là xác minh đường dẫn Merkle trong mạch). Để lưu trữ Ethereum, chúng tôi cần mạch này tương thích với cả cây Merkle-Patricia và hàm băm Keccak.

2. Chúng ta cần thiết kế một mạch để liên kết mã byte với dấu vết thực thi thực tế.

Di chuyển bytecode vào một mạch tĩnh đặt ra một vấn đề: opcodes có điều kiện như jump (trái ngược với vòng lặp, câu lệnh if other trong hợp đồng thông minh) có thể nhảy bất cứ đâu. Các đích nhảy không được xác định cho đến khi ai đó chạy mã byte đó với một đầu vào cụ thể. Đó là lý do tại sao chúng ta cần xác minh dấu vết thực thi thực tế. Một dấu vết thực thi có thể được coi là một "mã byte không được kiểm soát", chứa các opcode theo thứ tự chúng thực sự được thực thi (tức là nếu bạn chuyển đến một vị trí khác, opcode và vị trí đích đó sẽ được đưa vào dấu vết).

Người châm ngôn sẽ trực tiếp cung cấp dấu vết thực hiện dưới dạng dữ liệu nhân chứng của mạch. Chúng ta cần chứng minh rằng dấu vết thực thi thực sự là "không được kiểm soát" bởi một mã byte cụ thể với một đầu vào cụ thể. Ý tưởng là buộc giá trị của bộ đếm chương trình phải nhất quán. Đối với vấn đề về điểm đến không chắc chắn, giải pháp là yêu cầu người chứng minh cung cấp tất cả dữ liệu. Sau đó, bạn có thể sử dụng các tham số tra cứu để kiểm tra tính nhất quán một cách hiệu quả (nghĩa là chứng minh rằng opcode với bộ đếm toàn cầu chính xác được chứa trong "bus").

3. Ta cần thiết kế mạch cho từng opcode (để chứng minh việc đọc, ghi và tính toán trong mỗi opcode là chính xác).

Đây là phần quan trọng nhất - chứng minh rằng mỗi opcode trong theo dõi thực thi là chính xác và nhất quán. Nếu bạn chỉ đặt mọi thứ lại với nhau, sẽ có chi phí cao. Các ý tưởng tối ưu hóa quan trọng ở đây là:

• Chúng ta có thể tách R/W và tính toán thành hai bằng chứng. Một bằng chứng đặt tất cả các yếu tố được sử dụng bởi opcode trên "xe buýt". Một bằng chứng khác sẽ chứng minh rằng việc tính toán các phần tử trên "xe buýt" đã được thực hiện chính xác. Điều này giúp giảm đáng kể chi phí cho mỗi bộ phận (nghĩa là bạn không cần xem xét toàn bộ bộ lưu trữ EVM khi tạo bằng chứng tính toán). Trong một đặc điểm kỹ thuật chi tiết hơn, cái trước được gọi là "Bằng chứng trạng thái" và cái sau là "Bằng chứng EVM". Một phát hiện khác là các câu lệnh tra cứu có thể xử lý "ánh xạ xe buýt" một cách hiệu quả.

• Chúng ta có thể thiết kế mức độ ràng buộc tùy chỉnh cao hơn cho mỗi opcode (nghĩa là chúng ta có thể chia một từ EVM thành nhiều khối dữ liệu để xử lý hiệu quả hơn). Chúng ta có thể chọn có "bật" một ràng buộc theo yêu cầu thông qua đa thức chọn hay không. Điều này tránh chi phí tiêu thụ toàn bộ mạch EVM cho mỗi hoạt động.

Ban đầu được đề xuất bởi Ethereum Foundation, kiến ​​trúc này vẫn đang ở giai đoạn đầu và đang được phát triển tích cực. Chúng tôi đang hợp tác chặt chẽ với Ethereum Foundation để tìm ra cách tốt nhất để triển khai mạch EVM này. Cho đến nay, chúng tôi đã xác định các tính năng quan trọng nhất của mạch EVM và triển khai (sử dụng cú pháp UltraPlonk từ thư viện Halo2) một số mã lệnh (bấm vào đây để xem). Nội dung chi tiết hơn sẽ được giới thiệu trong các bài viết tiếp theo. Chúng tôi khuyên bạn đọc quan tâm nên đọc tài liệu này. Quá trình phát triển sẽ minh bạch. Đây sẽ là một thiết kế mã nguồn mở hoàn toàn được tập hợp bởi toàn bộ cộng đồng. Tôi hy vọng sẽ có nhiều người tham gia và đóng góp.

zkEVM có thể mang lại cho chúng ta điều gì khác?

zkEVM không chỉ mở rộng quy mô Lớp 2. Chúng ta có thể hiểu nó là một cách đơn giản để mở rộng quy mô bằng chứng tính hợp lệ của Ethereum Lớp 1 thông qua Lớp 1. Điều này có nghĩa là Lớp 1 hiện có có thể được mở rộng mà không cần bất kỳ Lớp 2 đặc biệt nào.

Tóm lại là

Tóm lại là

về chúng tôi

về chúng tôi

Ghi chú:

Ghi chú:

1. Khả năng kết hợp đã đạt được trong thông báo ngày 1 tháng 9 năm 2021 của Starkware (bấm vào đây để xem thông báo).

2. Mạch được cố định và tĩnh. Ví dụ: bạn không thể sử dụng các vòng lặp giới hạn trên có thể thay đổi khi triển khai chương trình dưới dạng một mạch. Giới hạn trên phải được cố định ở giá trị tối đa. Mạch không thể xử lý logic động.

3. Để thuận tiện cho người đọc, chúng tôi trình bày chi tiết chi phí của mạch EVM tại đây. Như đã nêu trước đó, các mạch là cố định và tĩnh. Do đó, mạch EVM cần chứa tất cả logic có thể (lớn hơn 10000 lần so với mạch chỉ chứa add). Điều này có nghĩa là ngay cả khi bạn chỉ muốn chứng minh thêm, bạn vẫn phải chịu chi phí cho tất cả logic có thể chứa trong mạch EVM này. Nghĩa là, chi phí được phóng đại theo hệ số 10.000. Trong theo dõi thực thi, bạn cần chứng minh một chuỗi opcode và mỗi opcode đều có chi phí cao.

4. Bản thân EVM không bị ràng buộc chặt chẽ với Cây Merkle-Patricia (MPT). Hiện tại, MPT chỉ được sử dụng để lưu trữ trạng thái Ethereum. Dễ dàng thay thế (có người đề xuất dùng cây Verkle để thay thế MPT).

5. Đây là một trừu tượng đơn giản hóa cao. Về mặt kỹ thuật, danh sách "trạng thái EVM" dài hơn, bao gồm bộ đếm chương trình, khoảng trống gas, ngăn xếp cuộc gọi (tất cả các địa chỉ trên cùng với địa chỉ và số liệu thống kê cho mỗi lệnh gọi trong ngăn xếp), một tập hợp nhật ký và biến phạm vi giao dịch (khe lưu trữ nóng , hoàn tiền, tự hủy). Ngoài ra, chúng tôi có thể giới thiệu số nhận dạng cho các môi trường gọi khác nhau để hỗ trợ trực tiếp khả năng kết hợp.

6. Vì dung lượng lưu trữ lớn nên chúng tôi sử dụng bộ tích lũy để lưu trữ. Bộ nhớ và ngăn xếp có thể được chỉnh sửa bằng Plookup (chúng ta có thể triển khai "RAM" một cách hiệu quả theo cách này).

7. Liên kết gốc:

Liên kết gốc:

https://hackmd.io/@yezhang/S1_KMMbGt