Bản gốc: Diệp Trương
Biên dịch: FF
Bài phát biểu được chia thành bốn phần. Trong phần đầu tiên, Zhang Ye đã giới thiệu nền tảng phát triển và lý do tại sao chúng ta cần zkEVM ngay từ đầu và tại sao nó lại trở nên phổ biến trong hai năm qua. Phần thứ hai giải thích cách xây dựng zkEVM từ đầu bao gồm số học thông qua một quy trình hoàn chỉnh và hệ thống chứng minh, phần thứ ba nói về các vấn đề mà Scroll gặp phải khi xây dựng zkEVM thông qua một số câu hỏi nghiên cứu thú vị và cuối cùng giới thiệu một số ứng dụng khác sử dụng zkEVM.
Bối cảnh và động lực
Trong chuỗi khối Lớp 1 truyền thống, một số nút sẽ được duy trì chung thông qua mạng P2P. Khi chúng nhận được giao dịch của người dùng, chúng sẽ được thực thi trong máy ảo của EVM, đọc hợp đồng gọi và lưu trữ, đồng thời cập nhật cây trạng thái toàn cầu theo giao dịch.
Ưu điểm của kiến trúc như vậy nằm ở tính phi tập trung và bảo mật, nhược điểm là phí giao dịch trên L1 đắt và xác nhận giao dịch chậm.
Trong kiến trúc ZK- Rollup, mạng L2 chỉ cần tải dữ liệu lên và xác minh tính chính xác của dữ liệu tới L1, trong đó bằng chứng được tính toán thông qua Zero-knowledge Proof.
Trong ZK- Rollup ban đầu, mạch được thiết kế cho các ứng dụng cụ thể, người dùng cần gửi giao dịch đến các chứng minh khác nhau, sau đó ZK- Rollup của các ứng dụng khác nhau gửi dữ liệu và chứng minh của riêng họ tới L1. Vấn đề do điều này gây ra là khả năng kết hợp của hợp đồng L1 ban đầu bị mất.
Những gì Scroll cần làm là một giải pháp zkEVM riêng, là một ZK- Rollup có mục đích chung. Điều này không chỉ thân thiện hơn với người dùng mà còn cho phép các nhà phát triển có được trải nghiệm phát triển trên L1. Tất nhiên, sự phát triển đằng sau điều này là rất khó khăn và chi phí tạo ra bằng chứng hiện tại cũng rất cao.
May mắn thay, hiệu quả của Zero-knowledge Proof đã được cải thiện đáng kể trong hai năm qua, đó là lý do tại sao zkEVM đã trở nên rất phổ biến trong hai năm qua. Có ít nhất bốn lý do để làm cho nó khả thi. Đầu tiên là sự xuất hiện của các cam kết đa thức. Theo hệ thống chứng minh Groth16 ban đầu, quy mô của các ràng buộc là rất lớn và các cam kết đa thức có thể hỗ trợ các ràng buộc bậc cao hơn và giảm quy mô của các bằng chứng ; thứ hai là Sự xuất hiện của các bảng tra cứu và cổng tùy chỉnh có thể hỗ trợ các thiết kế linh hoạt hơn và làm cho các bằng chứng hiệu quả hơn; thứ ba là một bước đột phá trong tăng tốc phần cứng, có thể rút ngắn thời gian bằng chứng xuống 1-2 bậc độ lớn thông qua GPU, FPGA và ASIC; thứ tư là Theo bằng chứng đệ quy, nhiều bằng chứng có thể được nén thành một bằng chứng, làm cho bằng chứng nhỏ hơn và dễ xác minh hơn. Do đó, kết hợp bốn yếu tố này, hiệu quả tạo ra Zero-knowledge Proof cao hơn ba bậc so với hai năm trước, đây cũng là nguồn gốc của Scoll.
Theo định nghĩa của Justin Drake, zkEVM có thể được chia thành ba loại. Loại đầu tiên là khả năng tương thích ở cấp độ ngôn ngữ. Lý do chính là EVM không được thiết kế cho ZK và có nhiều opcode không thân thiện với ZK, điều này sẽ gây ra rất nhiều chi phí bổ sung. . Vì vậy, giống như Starkware và zkSync chọn biên dịch Solidity hoặc Yul thành trình biên dịch thân thiện với ZK ở cấp độ ngôn ngữ.
Loại thứ hai là khả năng tương thích mức mã byte mà Scroll đang thực hiện, trực tiếp chứng minh quá trình xử lý mã byte của EVM có đúng hay không và trực tiếp kế thừa môi trường thực thi của Ethereum. Một số thỏa hiệp có thể được thực hiện ở đây là sử dụng gốc trạng thái khác với EVM, chẳng hạn như sử dụng cấu trúc dữ liệu thân thiện với ZK. Hermez và Consensys đang làm điều gì đó tương tự.
Loại thứ ba là khả năng tương thích ở cấp độ đồng thuận. Sự đánh đổi ở đây không chỉ là nhu cầu giữ EVM không thay đổi mà còn là cấu trúc lưu trữ để đạt được khả năng tương thích hoàn toàn với Ethereum. Cái giá phải trả là mất nhiều thời gian hơn để chứng minh. Và Scroll đang xây dựng với sự hợp tác của nhóm PSE của Ethereum Foundation để hiện thực hóa ZK của Ethereum
Xây dựng zkEVM từ 0 đến 1
Trong phần thứ hai, Zhang Ye đã chỉ cho mọi người cách xây dựng ZKVM từ đầu.
hoàn thành quá trình
Trước hết, trong phần giao diện người dùng của ZKP, bạn cần thể hiện các phép tính của mình thông qua số học toán học, thường được sử dụng nhất là R1CS tuyến tính, cũng như Plonkish và AIR. Sau khi thu được các ràng buộc thông qua phép tính số học, bạn cần chạy thuật toán chứng minh trên phần phụ trợ của ZKP để chứng minh tính đúng đắn của phép tính. .
Ở đây chúng ta cần chứng minh rằng zkEVM, Scroll sử dụng kết hợp Plonkish, Plonk IOP và KZG.
Để hiểu lý do tại sao chúng tôi sử dụng ba lược đồ. Đầu tiên chúng ta bắt đầu với R1CS đơn giản nhất.Ràng buộc trong R1CS là tổ hợp tuyến tính nhân với tổ hợp tuyến tính bằng tổ hợp tuyến tính. Bạn có thể thêm bất kỳ tổ hợp tuyến tính nào của các biến mà không cần thêm chi phí, nhưng thứ tự tối đa là 2 trong mỗi ràng buộc. Do đó, đối với các hoạt động bậc cao hơn, cần có nhiều ràng buộc hơn.
Trong khi ở Plonkish, bạn cần điền vào bảng tất cả các biến, bao gồm đầu vào, đầu ra và nhân chứng cho các biến trung gian. Trên hết, bạn có thể xác định các ràng buộc khác nhau. Có ba loại ràng buộc có sẵn trong Plonkish.
Ràng buộc đầu tiên là một cổng tùy chỉnh (Custom Gate), bạn có thể xác định mối quan hệ ràng buộc đa thức giữa các ô khác nhau, chẳng hạn như va3 * vb3 * vc3 - vb4 =0. So với R1CS, thứ tự có thể cao hơn, vì bạn có thể xác định các ràng buộc đối với bất kỳ biến nào và bạn có thể xác định một số ràng buộc rất khác.
Ràng buộc thứ hai là Permuation, tức là kiểm tra tương đương (eequity tests). Nó có thể được sử dụng để kiểm tra sự tương đương của các ô khác nhau và thường được sử dụng để liên kết các cổng khác nhau trong một mạch, chẳng hạn như chứng minh rằng đầu ra của cổng trước bằng đầu vào của cổng tiếp theo.
Loại ràng buộc cuối cùng là Bảng tra cứu. Ta có thể hiểu bảng tra cứu là mối quan hệ giữa các biến, có thể biểu diễn dưới dạng bảng. Ví dụ: chúng tôi muốn chứng minh rằng vc7 nằm trong khoảng 0-15, trong R1CS, trước tiên bạn cần phân tách giá trị này thành 4 bit nhị phân, sau đó chứng minh rằng mỗi bit nằm trong khoảng 0-1, điều này sẽ yêu cầu bốn ràng buộc. Trong Plonkish, bạn có thể liệt kê tất cả các phạm vi có thể có trong cùng một cột và bạn chỉ cần chứng minh rằng vc7 thuộc về cột đó, điều này rất hiệu quả cho việc chứng minh phạm vi.
Tóm lại, Plonkish cũng hỗ trợ các cổng tùy chỉnh, kiểm tra tương đương và bảng tra cứu, có thể rất linh hoạt để đáp ứng các nhu cầu mạch khác nhau. Khi so sánh đơn giản với STARK, mỗi hàng trong STARK là một ràng buộc và ràng buộc cần thể hiện sự chuyển đổi trạng thái giữa các hàng, nhưng các ràng buộc tùy chỉnh trong Plonkish rõ ràng là linh hoạt hơn.
Bây giờ câu hỏi là làm thế nào để chúng ta chọn giao diện người dùng trong zkEVM. Có bốn thách thức chính đối với zkEVM. Thách thức đầu tiên là trường của EVM là 256 bit, có nghĩa là các biến cần được ràng buộc một cách hiệu quả; thách thức thứ hai là EVM có nhiều mã lệnh không thân thiện với ZK, do đó cần có các ràng buộc quy mô rất lớn để chứng minh các hoạt động này mã, chẳng hạn như Keccak-256; thách thức thứ ba là vấn đề đọc và ghi bộ nhớ, bạn cần một số ánh xạ hiệu quả để chứng minh rằng những gì bạn đọc phù hợp với những gì bạn đã viết trước đó; thách thức thứ tư là dấu vết thực thi của EVM là Động , vì vậy chúng tôi cần các cổng tùy chỉnh để thích ứng với các dấu vết thực thi khác nhau. Đối với những cân nhắc trên, chúng tôi đã chọn Plonkish.
Tiếp theo, chúng ta hãy xem toàn bộ quá trình của zkEVM. Dựa trên cây trạng thái toàn cầu ban đầu, sau khi một giao dịch mới xuất hiện, EVM sẽ đọc mã byte của hợp đồng được lưu trữ và được gọi, đồng thời tạo ra các dấu vết thực thi tương ứng như PUSH, PUSH, CỬA HÀNG, CALLVALUE, sau đó từng bước cập nhật trạng thái toàn cầu để có được cây trạng thái toàn cầu sau giao dịch. zkEVM lấy cây trạng thái toàn cầu ban đầu, bản thân giao dịch và cây trạng thái toàn cầu sau giao dịch làm đầu vào và theo đặc tả EVM, nó chứng minh tính chính xác thực thi của dấu vết thực thi.
Chi tiết về mạch EVM chuyên sâu, mỗi bước của quá trình theo dõi thực thi có một ràng buộc mạch tương ứng. Cụ thể, các ràng buộc mạch của từng bước bao gồm Bối cảnh bước, Chuyển đổi trường hợp và Nhân chứng cụ thể của mã. Step Context chứa codehash tương ứng với dấu vết thực thi, gas còn lại và bộ đếm; Case Switch chứa tất cả các opcode, tất cả các điều kiện lỗi và hoạt động tương ứng của bước; Opcode Specific Witness chứa các nhân chứng bổ sung theo yêu cầu của opcode, chẳng hạn như toán hạng chờ.
Lấy phép cộng đơn giản làm ví dụ, cần đảm bảo rằng biến điều khiển sADD của opcode của phép cộng được đặt thành 1 và các biến điều khiển của các opcode khác đều bằng 0. Trong Step Context, hạn chế lượng gas tiêu thụ bằng 3 bằng cách đặt gas' - gas - 3 = 0. Tương tự, hạn chế bộ đếm và con trỏ ngăn xếp sẽ tích lũy 1 sau bước này; trong Case Switch, điều khiển biến tính tổng thành 1 thông qua opcode Để ràng buộc bước này là một thao tác cộng; trong Opcode Specific Witness, hạn chế việc cộng toán hạng thực tế.
Ngoài ra, các ràng buộc mạch bổ sung được yêu cầu để đảm bảo tính chính xác của toán hạng được đọc từ bộ nhớ. Ở đây, trước tiên chúng ta cần xây dựng một bảng tra cứu để chứng minh rằng toán hạng thuộc về bộ nhớ. Và thông qua mạch bộ nhớ (RAM Circuit) để xác minh tính đúng đắn của bảng bộ nhớ.
Phương pháp tương tự có thể được áp dụng cho các hàm băm không thân thiện với zk, xây dựng bảng tra cứu hàm băm, ánh xạ đầu vào và đầu ra của hàm băm trong dấu vết thực thi vào bảng tra cứu và sử dụng một mạch băm bổ sung (Mạch băm) để xác minh hash Hy vọng tính chính xác của bảng tra cứu.
Bây giờ hãy xem kiến trúc mạch của zkEVM. Mạch EVM lõi được sử dụng để hạn chế tính chính xác của từng bước của dấu vết thực thi. Ở một số nơi khó hạn chế mạch EVM, chúng tôi sử dụng bảng tra cứu để ánh xạ, bao gồm Bảng cố định , Bảng Keccak, Bảng RAM, Mã byte, Giao dịch, Ngữ cảnh khối, sau đó sử dụng các mạch riêng biệt để ràng buộc các bảng tra cứu này, ví dụ: mạch Keccak được sử dụng để ràng buộc bảng Keccak.
Tóm lại, toàn bộ quy trình làm việc của zkEVM được hiển thị trong hình bên dưới.
hệ thống bằng chứng
Do chi phí xác minh trực tiếp mạch EVM, mạch bộ nhớ, mạch lưu trữ, v.v. trên L1 là rất lớn nên hệ thống chứng minh của Scroll áp dụng kiến trúc hai lớp.
Lớp đầu tiên chịu trách nhiệm chứng minh trực tiếp bản thân EVM, đòi hỏi rất nhiều tính toán để tạo ra bằng chứng. Do đó, cần có hệ thống chứng minh cấp một để hỗ trợ các cổng tùy chỉnh và bảng tra cứu, thân thiện với khả năng tăng tốc phần cứng, tạo các phép tính song song trong bộ nhớ đỉnh thấp và xác minh rằng quy mô của mạch nhỏ và có thể được xác minh nhanh chóng . Các lựa chọn thay thế đầy hứa hẹn bao gồm Plonky2, Starky và eSTARK, về cơ bản sử dụng Plonk ở giao diện người dùng nhưng có thể sử dụng FRI ở giao diện sau và tất cả chúng đều đáp ứng bốn đặc điểm trên. Một loại sơ đồ tùy chọn khác bao gồm Halo2 do Zcash phát triển và Halo2 của phiên bản KZG.
Ngoài ra còn có một số hệ thống chứng minh mới hứa hẹn, chẳng hạn như HyperPlonk, hệ thống chứng minh FFT gần đây đã bị loại bỏ và hệ thống chứng minh NOVA có thể đạt được các chứng minh đệ quy nhỏ hơn. Nhưng họ chỉ hỗ trợ R1CS trong nghiên cứu, nếu sau này họ hỗ trợ được Plonkish và áp dụng vào thực tế thì sẽ rất thiết thực và hiệu quả.
Hệ thống bằng chứng cấp hai được sử dụng để chứng minh tính đúng đắn của bằng chứng cấp một và hệ thống này cần có khả năng xác minh hiệu quả trong EVM. Lý tưởng nhất là hệ thống này phải thân thiện với phần cứng được tăng tốc và hỗ trợ thiết lập minh bạch hoặc phổ quát. Các lựa chọn thay thế đầy hứa hẹn bao gồm Groth16 và hệ thống bằng chứng Plonkish với ít cột hơn. Groth16 vẫn là đại diện cho hiệu quả chứng minh cực cao trong nghiên cứu hiện tại và hệ thống chứng minh Plonkish cũng có thể đạt được hiệu quả chứng minh cao khi số lượng cột nhỏ.
Tại Scroll, chúng tôi đã áp dụng hệ thống chứng minh Halo2-KZG trong hệ thống chứng minh hai tầng. Vì Halo2-KZG có thể hỗ trợ các cổng tùy chỉnh và bảng tra cứu nên nó có hiệu suất tốt khi tăng tốc phần cứng GPU và mạch xác minh có quy mô nhỏ, có thể được xác minh nhanh chóng. Sự khác biệt là chúng tôi sử dụng hàm băm Poseidon trong hệ thống bằng chứng cấp một để cải thiện hiệu quả bằng chứng hơn nữa, trong khi hệ thống bằng chứng cấp hai vẫn sử dụng hàm băm Keccak vì nó được xác minh trực tiếp trên Ethereum. Scroll cũng đang khám phá khả năng của một hệ thống bằng chứng nhiều lớp để tổng hợp thêm các bằng chứng tổng hợp do hệ thống bằng chứng cấp hai tạo ra.
Theo cách triển khai hiện tại, mạch EVM hệ thống bằng chứng cấp một của Scroll có 116 cột, 2496 cổng tùy chỉnh, 50 bảng tra cứu, thứ tự cao nhất là 9 và 2^18 hàng được yêu cầu trong 1M Gas; trong khi bằng chứng cấp hai của hệ thống Mạch tổng hợp chỉ có 23 cột, 1 cổng tùy chỉnh, 7 bảng tra cứu và thứ tự cao nhất là 5. Để tổng hợp các mạch EVM, mạch bộ nhớ và mạch lưu trữ, cần có 2^25 hàng.
Scroll cũng đã thực hiện rất nhiều nghiên cứu và tối ưu hóa khả năng tăng tốc phần cứng GPU, đối với mạch EVM, trình xác nhận GPU được tối ưu hóa chỉ mất 30 giây, hiệu quả hơn 9 lần so với trình xác nhận CPU, và đối với mạch tổng hợp, GPU được tối ưu hóa prover chỉ mất 149 giây, hiệu quả gấp 15 lần so với CPU. Trong các điều kiện tối ưu hóa hiện tại, hệ thống kiểm chứng cấp một của 1M Gas mất khoảng 2 phút và hệ thống kiểm chứng cấp hai mất khoảng 3 phút.
câu hỏi nghiên cứu thú vị
Trong phần thứ ba, Zhang Ye đã nói về một số vấn đề nghiên cứu thú vị trong quá trình xây dựng zkEVM trong Scroll, từ mạch số học mặt trước đến việc hiện thực hóa câu tục ngữ.
mạch
Đầu tiên là tính ngẫu nhiên trong mạch, vì trường EVM là 256 bit, chúng ta cần chia nó thành 32 trường 8 bit để thực hiện kiểm chứng phạm vi hiệu quả hơn. Sau đó, chúng tôi sử dụng phương pháp kết hợp tuyến tính ngẫu nhiên (Random Linear Combination, RLC) sử dụng các số ngẫu nhiên để mã hóa 32 trường thành một và chỉ cần xác minh trường này để xác minh trường 256 bit ban đầu. Nhưng vấn đề là việc tạo số ngẫu nhiên cần phải được phân tách sau trường để đảm bảo rằng nó không bị giả mạo. Do đó, các nhóm Scroll và PSE đã đề xuất một sơ đồ chứng minh nhiều giai đoạn để đảm bảo rằng sau khi tách trường, các số ngẫu nhiên được sử dụng để tạo RLC. Sơ đồ này được gói gọn trong API Thách thức. RLC có nhiều kịch bản ứng dụng trong zkEVM. Nó không chỉ có thể nén các trường EVM thành một trường mà còn có thể mã hóa các đầu vào có độ dài thay đổi hoặc tối ưu hóa bố cục của các bảng tra cứu. Tuy nhiên, vẫn còn nhiều vấn đề mở cần giải quyết.
Một vấn đề nghiên cứu thú vị thứ hai về mạch là bố trí mạch. Lý do tại sao giao diện người dùng Scroll sử dụng Plonkish là do dấu vết thực thi của EVM đang thay đổi linh hoạt và nó cần có khả năng hỗ trợ các ràng buộc khác nhau và thay đổi các thử nghiệm tương đương, trong khi cổng tiêu chuẩn hóa của R1CS yêu cầu quy mô mạch lớn hơn để nhận ra . Tuy nhiên, Scroll hiện đang sử dụng hơn 2.000 cổng tùy chỉnh để đáp ứng các dấu vết thực thi thay đổi linh hoạt và cũng đang khám phá cách tối ưu hóa hơn nữa bố cục mạch, bao gồm tách Opcode thành Micro Opcode hoặc sử dụng lại các ô trong cùng một bảng.
Một vấn đề nghiên cứu thú vị thứ ba về mạch điện là quy mô động. Do quy mô mạch của các opcode khác nhau là khác nhau, nhưng để đáp ứng dấu vết thực thi thay đổi linh hoạt, opcode của mỗi bước cần đáp ứng quy mô mạch tối đa, chẳng hạn như băm Keccak, vì vậy chúng tôi thực sự phải trả thêm chi phí hoạt động. Giả sử chúng ta có thể tự động điều chỉnh zkEVM để tự động thay đổi dấu vết thực thi, điều này sẽ tiết kiệm chi phí không cần thiết.
người chứng nhận
Đối với người chứng minh, Scroll đã tối ưu hóa MSM và NTT về khả năng tăng tốc GPU, nhưng giờ đây, nút cổ chai đã chuyển sang tạo nhân chứng và sao chép dữ liệu. Giả sử rằng MSM và NTT chiếm 80% thời gian chứng minh, ngay cả khi khả năng tăng tốc phần cứng có thể cải thiện phần hiệu quả này theo một số bậc độ lớn, thì 20% thời gian chứng minh ban đầu để tạo nhân chứng và sao chép dữ liệu sẽ trở thành nút thắt cổ chai mới. Một vấn đề khác với chứng minh là nó đòi hỏi nhiều bộ nhớ, vì vậy cũng cần phải khám phá các giải pháp phần cứng rẻ hơn và phi tập trung hơn.
Đồng thời, Scroll cũng đang khám phá các thuật toán chứng minh và tăng tốc phần cứng để cải thiện hiệu quả của phép chứng minh. Hiện tại, có hai hướng chính hoặc chuyển sang miền nhỏ hơn, chẳng hạn như sử dụng miền Goldilocks 64 bit, Mersenne Prime 32 bit, v.v. hoặc bám vào hệ thống chứng minh mới dựa trên đường cong elliptic (EC), chẳng hạn như Siêu tân tinh. Đương nhiên, còn có những con đường khả thi khác, bằng hữu có ý kiến gì cứ trực tiếp liên hệ với Scroll.
sự an toàn
Bảo mật là điều tối quan trọng khi xây dựng zkEVM. ZkEVM do PSE và Scroll cùng xây dựng có khoảng 34.000 dòng mã, từ góc độ công nghệ phần mềm, các cơ sở mã phức tạp này không thể không có sơ hở trong một thời gian dài. Scroll hiện đang kiểm tra cơ sở mã zkEVM thông qua một số lượng lớn các cuộc kiểm tra, bao gồm cả các công ty kiểm toán hàng đầu trong ngành.
Các ứng dụng khác sử dụng zkEVM
Phần IV khám phá một số ứng dụng khác sử dụng zkEVM.
Trong kiến trúc của zkRollup, chúng tôi xác minh rằng n giao dịch trên L2 là hợp lệ thông qua hợp đồng thông minh trên L1.
Nếu chúng ta xác minh trực tiếp khối L1, thì nút L1 không cần thực hiện giao dịch nhiều lần mà chỉ cần xác minh tính hợp lệ của từng bằng chứng khối. Một giải pháp kiến trúc như vậy được gọi là Enshrine Blockchain. Hiện tại, rất khó để triển khai trực tiếp trên Ethereum, vì nó cần xác minh toàn bộ khối Ethereum, bao gồm xác minh một số lượng lớn chữ ký, điều này sẽ khiến thời gian xác minh lâu hơn và tính bảo mật thấp hơn. Tất nhiên, đã có một số chuỗi công khai khác sử dụng một bằng chứng duy nhất để xác minh toàn bộ chuỗi khối thông qua bằng chứng đệ quy, chẳng hạn như MINA.
Bởi vì zkEVM có thể chứng minh quá trình chuyển đổi trạng thái, nó cũng có thể được sử dụng bởi mũ trắng để chứng minh rằng họ biết sơ hở của một số hợp đồng thông minh và tìm kiếm tiền thưởng từ phía dự án.
Trường hợp sử dụng cuối cùng là chứng minh tuyên bố của dữ liệu lịch sử thông qua Zero-knowledge Proof và sử dụng nó như một cỗ máy tiên tri. Axiom hiện đang nghiên cứu các sản phẩm trong lĩnh vực này. Tại cuộc thi hackathon ETHBeijing gần đây, nhóm GasLockR đã tận dụng tính năng này để chứng minh chi phí Gas lịch sử.
Cuối cùng, Scroll đang xây dựng giải pháp mở rộng quy mô chung của zkRollup cho Ethereum, sử dụng hệ thống chứng minh và mạch số học rất tiên tiến, đồng thời xây dựng trình xác thực nhanh thông qua tăng tốc phần cứng để chứng minh đệ quy. Hiện mạng Alpha test đã ra mắt và chạy ổn định trong thời gian dài.
Tất nhiên, vẫn còn một số vấn đề thú vị cần giải quyết, bao gồm thiết kế giao thức và thiết kế cơ chế, kỹ thuật không kiến thức và hiệu quả thực tế. Hoan nghênh mọi người tham gia Scroll để cùng nhau xây dựng!
