- Chủ đề
4k Phổ biến
93k Phổ biến
15k Phổ biến
5k Phổ biến
30k Phổ biến
16k Phổ biến
23k Phổ biến
14k Phổ biến
3k Phổ biến
13k Phổ biến
- Ghim
4k Phổ biến
93k Phổ biến
15k Phổ biến
5k Phổ biến
30k Phổ biến
16k Phổ biến
23k Phổ biến
14k Phổ biến
3k Phổ biến
13k Phổ biến
V God Blog: Tìm hiểu về ví và các trường hợp ứng dụng khác Đọc chéo lớp 2
Tác giả: Vitalik Buterin; Biên dịch: Bulu said
Trong bài viết The Three Transitions, Vitalik Buterin, người sáng lập Ethereum, đã giải thích rõ ràng về "mạng chính (sau đây gọi là L1) + chuỗi chéo lớp 2 (sau đây gọi là cross-L2) hỗ trợ"" "Bảo mật ví" và "quyền riêng tư" là các giá trị quan trọng như các chức năng cần thiết của ngăn xếp hệ sinh thái. Chúng không nên chỉ là một số thành phần bổ sung và một ví riêng biệt cung cấp các chức năng liên quan.
Và bài viết này, Vitalik Buterin đã chỉ ra, sẽ tập trung vào một vấn đề kỹ thuật chính: làm thế nào để đọc dữ liệu L1 từ L2 dễ dàng hơn; hoặc đọc dữ liệu L2 từ L1; hoặc làm thế nào để đọc dữ liệu L2 từ L2 dễ dàng hơn Đọc dữ liệu từ L2 khác . **
Vitalik Buterin đã chỉ ra rằng chìa khóa để giải quyết các vấn đề trên nằm ở cách nhận ra sự tách biệt giữa tài sản và kho khóa. Công nghệ này cũng có các trường hợp sử dụng rất có giá trị trong các lĩnh vực khác ngoài quy mô, chẳng hạn như tính di động của tài sản giữa L1 và L2.
** Mục tiêu của việc này là gì? **
Khi L2 trở thành xu hướng chủ đạo, người dùng sẽ có thể sở hữu tài sản trên nhiều L2 và có thể cả L1 nữa.
Khi ví hợp đồng thông minh trở thành xu hướng chủ đạo, các "chìa khóa" phổ biến hiện nay sẽ không còn được sử dụng nữa.
Một khi hai điều này xảy ra cùng lúc, người dùng sẽ cần một phương pháp không yêu cầu số lượng lớn giao dịch để thay đổi khóa của các tài khoản khác nhau.
Cụ thể, chúng tôi cần một cách để xử lý các địa chỉ "phản thực tế" (còn được gọi là "địa chỉ giả định"): các địa chỉ chưa được "đăng ký" trên chuỗi theo bất kỳ cách nào, nhưng vẫn cần nhận và giữ tài sản một cách an toàn .
Trên thực tế, tất cả chúng ta đều dựa vào "cài đặt đối chứng" địa chỉ này: khi người dùng sử dụng Ethereum lần đầu tiên, người dùng có thể tạo địa chỉ ETH và những người khác có thể thanh toán vào tài khoản này mà không cần phải đăng ký trên chuỗi khối. địa chỉ (nhưng bạn sẽ phải trả phí giao dịch, vì vậy bạn cần giữ một số ETH).
Đối với các tài khoản bên ngoài (EOA), trên thực tế, tất cả các địa chỉ đều bắt đầu từ địa chỉ của "cài đặt đối chứng".
Các địa chỉ "được thiết lập ngược lại" vẫn có thể thực hiện được với các ví hợp đồng thông minh, phần lớn nhờ vào CREATE2, cho phép bạn có một địa chỉ ETH chỉ có thể được tạo bằng mã hợp đồng thông minh phù hợp với một hàm băm cụ thể.
△ Thuật toán tính toán địa chỉ EIP-1014 (CREATE2).
Tuy nhiên, việc giới thiệu ví hợp đồng thông minh cũng mang đến những thách thức mới: **Khóa truy cập có thể thay đổi. **Thay đổi này là địa chỉ là giá trị băm của initcode, chỉ có thể chứa khóa xác minh ban đầu của ví và khóa xác minh hiện tại sẽ được lưu trữ trong bộ lưu trữ của ví, nhưng bản ghi lưu trữ sẽ không được lưu trữ tự động chuyển sang L2 khác.
Nếu người dùng có địa chỉ trên nhiều L2, thì chỉ có Tách Kiến trúc Lưu trữ Khóa và Nội dung mới có thể giúp người dùng thay đổi khóa của họ.
Cấu trúc của kiến trúc phân tách này là mỗi người dùng có (i) "hợp đồng lưu trữ khóa" (trên chuỗi L1 hoặc chuỗi L2 cụ thể) lưu trữ khóa xác minh cho tất cả các ví và quy tắc thay đổi khóa và (ii) "Hợp đồng ví " trên L1 và nhiều chuỗi L2, chuỗi này nhận được khóa xác minh thông qua các lần đọc chuỗi chéo.
Có hai cách để triển khai kiến trúc phân tách bộ nhớ khóa và nội dung:
Phiên bản nhẹ (tức là chỉ kiểm tra các khóa được cập nhật): Mỗi ví lưu trữ cục bộ khóa xác minh và chứa chức năng có thể gọi được để kiểm tra bằng chứng chuỗi chéo về trạng thái hiện tại của kho khóa và cập nhật bộ nhớ cục bộ Xác thực chìa khóa để phù hợp. Gọi chức năng này để lấy khóa xác thực hiện tại từ kho khóa là bắt buộc khi sử dụng ví lần đầu tiên trên L2.
Phiên bản đầy đủ (tức là mọi giao dịch đều được kiểm tra): Mọi giao dịch đều yêu cầu bằng chứng chuỗi chéo hiển thị khóa hiện tại trong kho khóa.
**Bằng chứng xuyên chuỗi là gì? **
Để chứng minh sự phức tạp của bằng chứng chuỗi chéo, chúng tôi đã chọn một trong những kịch bản ứng dụng phức tạp nhất để chứng minh và giải thích nguyên tắc kỹ thuật này. Kịch bản ứng dụng phức tạp này như sau: khóa được lưu trữ trên một L2 và ví được bật L2 khác. Nếu kho khóa trên ví nằm trên L1, thì chỉ cần một nửa thiết kế này.
Giả sử kho khóa nằm trên Linea và ví nằm trên Kakarot. Quy trình chứng nhận hoàn chỉnh của khóa ví cần bao gồm:
Có hai câu hỏi triển khai hóc búa chính ở đây: "Loại bằng chứng nào cần được sử dụng? (Đó có phải là bằng chứng Merkle không? Hay cái gì khác?)" và "Làm cách nào để L2 học gốc trạng thái L1 gần nhất?" Hoặc, "L1 Làm thế nào để tìm hiểu gốc trạng thái của L2?"
Vì vậy, trong cả hai trường hợp, khoảng thời gian từ khi một sự kiện xảy ra ở một bên đến khi bên kia có thể cung cấp bằng chứng là bao lâu?
**Những chương trình bằng chứng nào có sẵn cho chúng tôi? **
Có năm phương pháp chính để lựa chọn:
Về công việc cơ sở hạ tầng cần thiết và chi phí người dùng, chúng có thể được xếp hạng đại khái như sau:
"Tổng hợp" đề cập đến việc tổng hợp tất cả các bằng chứng do người dùng cung cấp trong mỗi khối thành một bằng chứng meta lớn, hợp nhất chúng lại với nhau. Điều này phù hợp với SNARK và KZG, nhưng không phù hợp với Merkle fork.
Trên thực tế, tính “tổng hợp” chỉ có giá trị khi giải pháp có số lượng lớn người dùng.
** Bằng chứng Merkle hoạt động như thế nào? **
Vấn đề này rất đơn giản và có thể được thực hiện trực tiếp theo sơ đồ trong phần trước. Mỗi "bằng chứng" (giả sử rằng một L2 được chứng minh là một L2 khác, đây là kịch bản ứng dụng khó khăn nhất) sẽ bao gồm:
Một ngã ba Merkle chứng thực nắm giữ trạng thái gốc của kho khóa L2, gốc trạng thái mới nhất của Ethereum được L2 biết đến. Các gốc trạng thái chứa kho khóa L2 được lưu trữ trong các khe lưu trữ đã biết tại các địa chỉ đã biết (hợp đồng L1 đại diện cho L2), vì vậy các đường dẫn có thể được mã hóa cứng.
Một nhánh Merkle chứng thực khóa xác minh hiện tại, theo trạng thái gốc nắm giữ kho khóa L2. Ngoài ra, các khóa xác thực được lưu trữ trong các vị trí đã biết tại các địa chỉ đã biết, vì vậy các đường dẫn có thể được mã hóa cứng.
Tuy nhiên, các bằng chứng trạng thái trong Ethereum rất phức tạp, nhưng có những thư viện có thể được sử dụng để xác minh chúng và nếu sử dụng các thư viện này thì cơ chế cũng không quá phức tạp.
Tuy nhiên, thách thức lớn hơn là chi phí. **Merkle đã được chứng minh là rất dài và cây Patricia dài hơn mức cần thiết 3,9 lần - cao hơn nhiều so với giá cơ sở hiện tại là 21.000 Phí gas cho mỗi giao dịch.
Tuy nhiên, nếu bằng chứng được xác minh trên L2, sự khác biệt sẽ trở nên tồi tệ hơn. Tính toán bên trong L2 rẻ vì tính toán được thực hiện ngoài chuỗi và trong một hệ sinh thái có ít nút hơn L1.
Chúng ta có thể tính toán điều này có nghĩa là gì bằng cách xem so sánh giữa chi phí Phí gas L1 và chi phí Phí gas L2:
Hiện tại, nếu thao tác gửi tương đối đơn giản, chi phí trên mạng L1 gấp khoảng 15 ~ 25 lần so với L2 và chi phí trao đổi Mã thông báo gấp khoảng 20 ~ 50 lần so với L2.
Thao tác gửi đơn giản có lượng dữ liệu lớn; và thao tác trao đổi yêu cầu sức mạnh tính toán cao hơn, vì vậy thao tác trao đổi là điểm chuẩn tốt hơn để tính gần đúng chi phí tính toán L1 và tính toán L2.
Kết hợp những điều trên lại với nhau, nếu chúng ta giả sử tỷ lệ chi phí là 30 lần giữa chi phí tính toán L1 và chi phí tính toán L2, thì điều này có vẻ ngụ ý rằng chi phí đưa bằng chứng Merkle vào L2 có thể tương đương với khoảng 50 giao dịch thông thường.
Tất nhiên, việc sử dụng cây Merkle nhị phân sẽ giảm chi phí xuống khoảng 4 lần, nhưng ngay cả khi đó, chi phí vẫn rất cao trong hầu hết các trường hợp và nếu chúng tôi sẵn sàng từ bỏ khả năng tương thích với cây trạng thái hexa hiện tại của Ethereum, điều đó có thể Sẽ tìm kiếm các lựa chọn tốt hơn.
** Bằng chứng ZK-SNARK hoạt động như thế nào? **
Việc sử dụng ZK-SNARK cũng dễ hiểu về mặt khái niệm: bạn chỉ cần thay thế các bằng chứng Merkle trong sơ đồ trên bằng các ZK-SNARK chứng minh sự tồn tại của các bằng chứng Merkle đó. Số tiền tính toán của ZK-SNARK là khoảng 400.000 Phí gas, khoảng 400 byte; một giao dịch cơ bản yêu cầu 21.000 Phí gas và 100 byte.
Do đó, từ quan điểm tính toán, chi phí của ZK-SNARK gấp 19 lần chi phí giao dịch cơ bản hiện tại; từ quan điểm dữ liệu, chi phí của ZK-SNARK gấp 4 lần chi phí giao dịch cơ bản hiện tại và 16 lần trong tương lai phí giao dịch cơ bản.
Những con số này thể hiện một cải tiến lớn so với bằng chứng Merkle, nhưng vẫn còn khá đắt. Có hai cách để cải thiện tình trạng này: (i) bằng chứng KZG có mục đích đặc biệt hoặc (ii) tổng hợp, tương tự như tổng hợp ERC-4337.
** Bằng chứng KZG cho mục đích đặc biệt hoạt động như thế nào? **
Đầu tiên, một bản tóm tắt về cách thức hoạt động của những lời hứa KZG:
*[D_1 ...D_n] đại diện cho một tập hợp dữ liệu mà qua đó chứng minh KZG đa thức được lấy. *
*Cụ thể, đa thức P, trong đó P(w) = D_1, P(w²) = D_2 ... P(wⁿ) = D_n. w ở đây là "căn bậc nhất", đối với một số trường đánh giá kích thước N, giá trị wN = 1 (tất cả điều này được thực hiện trong trường hữu hạn). *
G là điểm tạo của đường cong
Pi là hệ số thứ i của đa thức P
Si là điểm thứ i trong cài đặt tin cậy
*Và để chứng minh rằng P(z) = a, chúng ta tạo một đa thức thương Q = (P - a)/(X - z), và tạo một cam kết com(Q). Chỉ có thể tạo một đa thức như vậy nếu P(z) thực sự bằng a. *
Một số thuộc tính chính cần biết bao gồm:
Bằng chứng chỉ là giá trị com(Q), là 48 byte
*Điều này cũng có nghĩa là bạn có thể "chỉnh sửa" giá trị trong một hợp đồng hiện có. *
Giả sử chúng tôi biết rằng D_i hiện tại là a, chúng tôi muốn đặt nó thành b và cam kết hiện tại với D là com(P). lời hứa "P, nhưng P(wⁱ) = b và không có đánh giá nào khác thay đổi", sau đó chúng tôi đặt com(new_P) = com(P) + (ba)*com(Li), trong đó Li là "lag Langerian đa thức", bằng 1 tại wⁱ và 0 tại các điểm wj khác. *
Để thực hiện các cập nhật này một cách hiệu quả, mỗi khách hàng có thể tính toán trước và lưu trữ tất cả N cam kết đối với đa thức Lagrange (com(Li)). Trong một hợp đồng trên chuỗi, có thể quá nhiều để lưu trữ tất cả N cam kết, vì vậy bạn có thể thực hiện các cam kết KZG đối với tập hợp các giá trị com(L_i), vì vậy, bất cứ khi nào ai đó cần cập nhật cây trên chuỗi, họ có thể chỉ cần gửi đúng com(L_i) cung cấp bằng chứng về tính đúng đắn của nó. *
Vì vậy, hãy có một cấu trúc tiếp tục thêm các giá trị vào cuối danh sách đang phát triển, nhưng với một giới hạn kích thước nhất định. Sau đó, sử dụng cấu trúc này làm cấu trúc dữ liệu cho (i) các cam kết đối với danh sách các khóa trên mỗi L2, được lưu trữ trên L2 đó và được nhân đôi với L1 và (ii) các cam kết đối với danh sách các cam kết đối với các khóa L2, được lưu trữ trong Ethereum trên L1 và được nhân đôi cho mỗi L2.
Việc cập nhật các cam kết có thể là một phần của logic L2 cốt lõi hoặc được triển khai thông qua cầu gửi và rút tiền mà không thay đổi giao thức lõi L2.
Một bằng chứng đầy đủ yêu cầu như sau:
Trên thực tế, hai bằng chứng KZG ở trên có thể được kết hợp thành một với tổng kích thước chỉ 100 byte.
Lưu ý một chi tiết: Vì danh sách khóa là một danh sách, không phải là bản đồ khóa/giá trị như trạng thái nên danh sách khóa phải được chỉ định vị trí theo thứ tự. Hợp đồng hứa hẹn khóa sẽ chứa sổ đăng ký nội bộ của riêng nó, ánh xạ mỗi kho khóa thành một ID và đối với mỗi khóa, nó sẽ lưu trữ hàm băm (khóa, địa chỉ của kho khóa) thay vì chỉ khóa, để thông báo rõ ràng cho các L2 khác về điều gì keystore một mục cụ thể đề cập đến.
Ưu điểm của kỹ thuật này là nó hoạt động rất tốt trên L2. Ngắn hơn khoảng 4 lần so với ZK-SNARK, ngắn hơn nhiều so với bằng chứng Merkle. Chi phí tính toán là khoảng 119.000 đồng Phí Gas.
Trên L1, sức mạnh tính toán quan trọng hơn dữ liệu, vì vậy KZG đắt hơn một chút so với bằng chứng Merkle.
** Cây Verkle hoạt động như thế nào? **
Cây Verkle về cơ bản liên quan đến việc xếp chồng các cam kết KZG lại với nhau: để lưu trữ các giá trị 2⁴⁸, một cam kết KZG có thể được tạo thành một danh sách các giá trị 2²⁴, mỗi trong số đó tự nó là một cam kết KZG đối với các giá trị 2²⁴.
Cây Verkle được xem xét cho cây trạng thái Ethereum vì cây Verkle có thể được sử dụng để giữ bản đồ khóa-giá trị.
Bằng chứng trong cây Verkle dài hơn bằng chứng KZG, chúng có thể dài hàng trăm byte.
Trên thực tế, cây Verkle nên được coi như cây Merkle, nhưng khả thi hơn nếu không có SNARKing, nhưng SNARKing đã được chứng minh là có chi phí chứng minh thấp hơn.
Ưu điểm lớn của cây Verkle là chúng có thể phối hợp các cấu trúc dữ liệu: vì vậy chúng có thể được sử dụng trực tiếp cho L1 hoặc L2, không có cấu trúc chồng chất và cơ chế giống hệt nhau được sử dụng cho L1 và L2.
Một khi máy tính lượng tử trở thành một vấn đề, hoặc một khi các nhánh Merkle chứng tỏ đủ hiệu quả, cây Verkle sẽ có nhiều công dụng hơn.
** trùng hợp **
Nếu N người dùng thực hiện N giao dịch và cần chứng minh N khiếu nại xuyên chuỗi, chúng tôi có thể tiết kiệm rất nhiều Phí gas bằng cách tổng hợp các bằng chứng này, điều này có thể có nghĩa là:
Cả 3 trường hợp này, mỗi bằng chứng chỉ mất vài trăm nghìn tiền Gas.
Các nhà phát triển cần tạo một bằng chứng như vậy trên mỗi L2 cho người dùng của L2 đó; do đó, để bằng chứng này trở nên hữu ích, toàn bộ chương trình cần phải có đủ mức sử dụng mà thường có ít nhất một vài giao dịch.
Nếu sử dụng ZK-SNARK, mỗi người dùng có thể phải chi hàng nghìn đô la Phí gas L2. Nếu sử dụng đa bằng chứng KZG, người xác minh cần thêm 48 Phí Gas vào L2 của mỗi kho khóa được sử dụng trong khối.
Tuy nhiên, những chi phí này thấp hơn nhiều so với việc không tổng hợp, điều này chắc chắn liên quan đến hơn 10.000 phí gas L1 và hàng trăm nghìn phí gas L2 cho mỗi người dùng.
Đối với cây Verkle, người dùng có thể trực tiếp sử dụng Verkle multi-proof, mỗi người dùng thêm khoảng 100 ~ 200 byte hoặc bạn có thể thực hiện ZK-SNARK multi-proof Verkle, chi phí của nó tương tự như ZK-SNARK của nhánh Merkle, nhưng bằng chứng Nó trông rõ ràng là rẻ tiền.
Từ quan điểm triển khai, tốt nhất nên để các trình đóng gói tổng hợp bằng chứng chuỗi chéo thông qua tiêu chuẩn trừu tượng hóa tài khoản ERC-4337. ERC-4337 đã có cơ chế để người xây dựng tổng hợp các phần của Hoạt động người dùng theo cách tùy chỉnh. Thậm chí còn có một triển khai cho tổng hợp chữ ký BLS, có thể giảm Phí gas L2 từ 1,5 lần đến 3 lần.
** Đọc trạng thái trực tiếp **
Khả năng cuối cùng và một khả năng chỉ áp dụng cho L2 đọc L1 (chứ không phải L1 đọc L2), là sửa đổi L2 để chúng trực tiếp thực hiện các lệnh gọi tĩnh tới các hợp đồng của L1.
Điều này có thể được thực hiện với một opcode hoặc tiền biên dịch cho phép các cuộc gọi đến L1 nơi bạn cung cấp địa chỉ đích, gas và calldata và nó trả về đầu ra, mặc dù vì các cuộc gọi này là tĩnh nên chúng thực sự không thể thay đổi bất kỳ trạng thái L1 nào. L2 phải biết điều gì đang xảy ra với L1 để xử lý tiền gửi, vì vậy không có yếu tố cơ bản nào ngăn cản điều này khả thi; nó chủ yếu là một thách thức triển khai kỹ thuật.
Lưu ý rằng nếu kho khóa nằm trên L1 và L2 kết hợp chức năng gọi tĩnh của L1, thì không cần chứng thực gì cả.
Tuy nhiên, nếu L2 không kết hợp các cuộc gọi tĩnh L1 hoặc nếu kho khóa nằm trên L2, thì cần phải có bằng chứng.
** Làm cách nào để L2 tìm hiểu gốc trạng thái Ethereum gần đây nhất? **
Tất cả các sơ đồ trên đều yêu cầu L2 truy cập vào gốc trạng thái L1 gần nhất hoặc toàn bộ trạng thái L1 gần nhất.
Trên thực tế, nếu L2 có chức năng gửi tiền, thì bạn có thể sử dụng L2 đó để chuyển gốc trạng thái L1 thành hợp đồng trên L2: chỉ cần có hợp đồng trên L1, gọi opcode BLOCKHASH và gửi nó dưới dạng tài sản. đến L2. Tiêu đề khối đầy đủ có thể được nhận ở phía L2 và gốc trạng thái của nó được trích xuất.
Tuy nhiên, mỗi L2 tốt nhất là có một cách rõ ràng để truy cập trực tiếp vào trạng thái L1 mới nhất đầy đủ hoặc gốc trạng thái L1 gần nhất.
Thách thức chính trong việc tối ưu hóa cách L2 nhận gốc trạng thái L1 mới nhất là đồng thời đạt được tính bảo mật và độ trễ thấp:
Ngoài ra, theo hướng ngược lại (L1 đọc L2):
Một số trong số chúng chậm đến mức không thể chấp nhận được đối với các hoạt động xuyên chuỗi không tin cậy đối với nhiều trường hợp sử dụng DeFi. Tuy nhiên, đối với trường hợp sử dụng cập nhật khóa ví, việc trì hoãn lâu hơn sẽ được chấp nhận hơn - vì thay vì trì hoãn giao dịch, nó sẽ trì hoãn các thay đổi về khóa.
Người dùng chỉ cần giữ chìa khóa cũ trong một khoảng thời gian dài hơn. Nếu người dùng thay đổi khóa vì nó đã bị đánh cắp, thì thực sự có một thời gian dài dễ bị tổn thương, nhưng nó có thể được giảm thiểu, chẳng hạn. Thông qua ví có chức năng đóng băng.
Cuối cùng, giải pháp giảm thiểu độ trễ tốt nhất là để L2 triển khai tối ưu việc đọc trực tiếp gốc trạng thái L1, trong đó mỗi khối L2 (hoặc nhật ký tính toán gốc trạng thái) chứa một con trỏ tới khối L1 mới nhất, vì vậy nếu L1 phục hồi và L2 cũng có thể phục hồi. Hợp đồng kho khóa phải được đặt trên mạng chính hoặc trên L2 của ZK-rollup để có thể nhanh chóng cam kết với L1.
** Chuỗi khác cần bao nhiêu kết nối với Ethereum để giữ kho khóa được lưu trữ trong ví Ethereum hoặc L2? **
Đáng ngạc nhiên, không nhiều như vậy. Trên thực tế, nó thậm chí không cần phải là một Tổng số.
Nếu đó là L3 hoặc hợp lệ, bạn có thể lưu trữ ví ở đó, miễn là người dùng lưu trữ khóa trên L1 hoặc ZK-rollup, họ thực sự cần có quyền truy cập trực tiếp vào trạng thái gốc của Ethereum và sẵn sàng lưu trữ ví của họ trên Ethereum Khi tái cấu trúc, hard fork khi Ethereum hard fork.
Các kế hoạch dựa trên cầu ZK có các đặc tính kỹ thuật hấp dẫn, nhưng chúng có một điểm yếu chính ở chỗ chúng không mạnh mẽ trước các cuộc tấn công 51% hoặc các đợt hard fork.
bảo vệ quyền riêng tư
Lý tưởng nhất là người dùng cũng muốn có sự riêng tư. Nếu người dùng có nhiều ví được quản lý bởi cùng một kho khóa, thì họ muốn đảm bảo rằng:
Nhưng điều này tạo ra một vấn đề:
Đối với SNARK, giải pháp đơn giản về mặt khái niệm: bằng chứng được ẩn thông tin theo mặc định và bộ tổng hợp cần tạo SNARK đệ quy để chứng minh SNARK.
Thách thức chính hiện tại với phương pháp này là việc tổng hợp yêu cầu trình tổng hợp tạo một SNARK đệ quy, quá trình này khá chậm.
Đối với KZG, chúng tôi có thể sử dụng tính năng không lập chỉ mục để tiết lộ công việc của bằng chứng KZG. Tuy nhiên, tập hợp mù là một vấn đề mở cần được chú ý nhiều hơn.
Tuy nhiên, trong khi đọc L1 trực tiếp từ bên trong L2 không bảo vệ quyền riêng tư, việc triển khai khả năng đọc trực tiếp này vẫn sẽ rất hữu ích - không chỉ để giảm thiểu độ trễ mà còn cho nhiều trường hợp sử dụng khác.