Tác giả: Vitalik Buterin Biên dịch: Vernacular Blockchain
Trong bài viết trước của tôi về ba ca làm việc, tôi đã nêu ra một số lý do chính tại sao việc bắt đầu suy nghĩ rõ ràng về hỗ trợ L1 + chéo L2, bảo mật ví và quyền riêng tư là rất có giá trị vì các tính năng cơ bản cần thiết của ngăn xếp hệ sinh thái Mọi thứ được xây dựng dưới dạng plugin có thể được thiết kế riêng bởi một ví duy nhất.
Bài đăng này sẽ tập trung trực tiếp hơn vào các khía cạnh kỹ thuật của một bài toán con cụ thể, chẳng hạn như: cách đọc L1 dễ dàng hơn từ L2, L2 từ L1 hoặc L2 từ L2 khác. Giải quyết vấn đề này là rất quan trọng để kích hoạt kiến trúc phân tách nội dung/kho khóa, nhưng nó cũng có các trường hợp sử dụng có giá trị trong các lĩnh vực khác, đáng chú ý nhất là tối ưu hóa các chuỗi cuộc gọi chéo L2 đáng tin cậy, bao gồm các trường hợp sử dụng như di chuyển nội dung giữa L1 và L2 .
** Danh mục bài viết này **
Mục tiêu là gì?
Bằng chứng chuỗi chéo trông như thế nào?
Chúng ta có thể sử dụng loại sơ đồ chứng minh nào?
Bằng chứng Merkle
ZK SNARK
Giấy chứng nhận KZG chuyên dụng
Bằng chứng cây Verkle
trùng hợp
đọc trạng thái trực tiếp
Làm cách nào để L2 tìm hiểu gốc trạng thái Ethereum gần đây nhất?
Ví trên chuỗi không phải L2
bảo vệ quyền riêng tư
tóm tắt
1. Mục tiêu là gì?
Sau khi L2 trở thành xu hướng chủ đạo, người dùng sẽ sở hữu tài sản trên nhiều L2 và có thể cả L1 nữa. Sau khi ví hợp đồng thông minh (đa chữ ký, khôi phục xã hội hoặc cách khác) trở thành xu hướng chủ đạo, các khóa cần thiết để truy cập một số tài khoản nhất định sẽ thay đổi theo thời gian và các khóa cũ hơn sẽ không còn hợp lệ nữa. Một khi hai điều đó xảy ra, người dùng sẽ cần một cách để thay đổi các khóa có quyền truy cập vào nhiều tài khoản ở nhiều nơi khác nhau mà không thực hiện một số lượng giao dịch cực lớn.
Cụ thể, chúng tôi cần một cách để xử lý các địa chỉ phản thực: 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ữ tiền một cách an toàn. Tất cả chúng ta đều dựa vào các địa chỉ phản thực: khi bạn sử dụng Ethereum lần đầu tiên, bạn có thể tạo địa chỉ ETH mà ai đó có thể sử dụng để thanh toán cho bạn mà không cần "đăng ký" địa chỉ trên chuỗi (điều này yêu cầu trả phí txfee, vì vậy hãy giữ một số ETH).
Đối với EOA, tất cả các địa chỉ đều bắt đầu bằng một địa chỉ phản thực. Với ví hợp đồng thông minh, các địa chỉ phản thực vẫn có thể thực hiện được phần lớn nhờ vào CREATE2, cho phép bạn có một địa chỉ ETH mà chỉ hợp đồng thông minh mới có thể điền vào bằng mã khớ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, ví hợp đồng thông minh đưa ra một thách thức mới: khả năng thay đổi khóa truy cập. Địa chỉ này là mã băm của mã khởi tạo và chỉ có thể chứa khóa xác minh ban đầu của 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 lan truyền một cách kỳ diệu đến các L2 khác.
Nếu người dùng có nhiều địa chỉ trên nhiều L2, bao gồm cả các địa chỉ mà họ đang sử dụng trên L2 mà họ không biết (vì chúng không có thực), thì dường như chỉ có một cách để cho phép người dùng thay đổi khóa của họ: kiến trúc phân tách tài sản/kho khóa. Mỗi người dùng có (i) một "hợp đồng lưu trữ khóa" (trên L1 hoặc một 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í" đọc trên các chuỗi để tìm khóa xác minh.
Có hai cách để đạt được điều này:
Phiên bản nhẹ (chỉ kiểm tra các khóa được cập nhật): Mỗi ví lưu trữ khóa xác minh cục bộ và chứa một chức năng có thể được gọi để 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 khóa xác minh được lưu trữ cục bộ của nó cho phù hợp. Khi ví được sử dụng lần đầu tiên trên một L2 cụ thể, chức năng này phải được gọi để lấy khóa xác thực hiện tại từ kho khóa.
-Ưu điểm: Bằng chứng xuyên chuỗi được sử dụng ít, vì vậy không thành vấn đề nếu bằng chứng xuyên chuỗi đắt tiền. Tất cả tiền chỉ có thể được sử dụng với khóa hiện tại, vì vậy nó vẫn an toàn.
Nhược điểm: Để thay đổi khóa xác minh, bạn phải thực hiện thay đổi khóa trên chuỗi trong kho khóa và trong mọi ví được khởi tạo (mặc dù không phải là ví phản thực). Điều này có thể tốn rất nhiều xăng.
Phiên bản nặng (kiểm tra mọi tx): 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.
Ưu điểm: ít phức tạp hệ thống hơn, cập nhật keystore rẻ.
Nhược điểm: Một tx đắt tiền, vì vậy cần nhiều kỹ thuật hơn để làm cho bằng chứng chuỗi chéo rẻ hơn nhiều. Cũng không dễ dàng tương thích với ERC-4337, hiện không hỗ trợ đọc các đối tượng có thể thay đổi trên các hợp đồng trong quá trình xác minh.
2. Bằng chứng chuỗi chéo trông như thế nào?
Để chứng minh sự phức tạp đầy đủ, chúng ta sẽ khám phá trường hợp khó khăn nhất: kho khóa trên một L2, ví trên một L2 khác. Chỉ cần một nửa thiết kế này nếu kho khóa trên ví nằm trên L1.
Giả sử kho khóa nằm trên Linea và ví nằm trên Kakarot. Bằng chứng đầy đủ về khóa ví bao gồm:
Bằng chứng về gốc trạng thái Linea hiện tại, dựa trên gốc trạng thái Ethereum hiện tại mà Kakarot đã biết
Bằng chứng về khóa hiện tại trong kho khóa, với gốc trạng thái Linea hiện tại
Có hai vấn đề triển khai phức tạp chính ở đây:
Chúng ta sử dụng loại bằng chứng nào? (Đó có phải là bằng chứng của bà Merkel không? Cái gì khác?
Làm thế nào để L2 lần đầu tiên tìm hiểu gốc trạng thái L1 (Ethereum) gần nhất (hoặc, như chúng ta sẽ thấy, có thể là trạng thái L1 đầy đủ)? Hoặc, làm thế nào để L1 tìm hiểu gốc trạng thái L2?
Trong cả hai trường hợp, độ trễ giữa những gì xảy ra ở một bên và những gì có thể chứng minh được ở bên kia là bao lâu?
3. Chúng ta có thể sử dụng những loại sơ đồ chứng minh nào?
Có năm lựa chọn chính:
-Bằng chứng Merkle
-Chung ZK-SNARK
Bằng chứng chuyên dụng (ví dụ: sử dụng KZG)
-Verkle chứng minh rằng họ nằm giữa KZG và ZK-SNARK về khối lượng công việc và chi phí cơ sở hạ tầng.
Không cần bằng chứng, dựa vào việc đọc trạng thái trực tiếp
Về công việc cơ sở hạ tầng cần thiết và chi phí người dùng, tôi sẽ xếp hạng chúng 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 kết hợp tất cả các bằng chứng. Điều này có thể thực hiện được với SNARK và KZG, nhưng không phải với Merkle fork (bạn có thể kết hợp Merkle fork một chút, nhưng nó chỉ giúp bạn tiết kiệm nhật ký (txs trên mỗi khối)/log (tổng số kho khóa), trên thực tế, có thể là 15-30% ở giữa, vì vậy nó có thể không đáng giá).
Việc tổng hợp chỉ trở nên có giá trị khi kịch bản có số lượng người dùng lớn, do đó, trong thực tế, việc triển khai phiên bản 1 có thể bỏ qua việc tổng hợp và triển khai nó trong phiên bản 2.
4. Bằng chứng Merkle sẽ hoạt động như thế nào?
Điều này rất dễ dàng: chỉ cần làm theo sơ đồ trong phần trước. Chính xác hơn, mỗi "bằng chứng" (giả sử trường hợp chứng minh độ khó tối đa của L2 này với L2 khác) sẽ chứa:
Một nhánh Merkle chứng thực trạng thái gốc của L2 đang nắm giữ kho khóa, với trạng thái gốc mới nhất của Ethereum mà L2 biết đến. Kho khóa chứa gốc trạng thái của L2 được lưu trữ trong một khe lưu trữ đã biết tại một địa chỉ đã biết (hợp đồng trên L1 đại diện cho L2), vì vậy đường dẫn qua cây có thể được mã hóa cứng.
Nhánh Merkle chứng thực khóa xác minh hiện tại, với gốc trạng thái của L2 đang nắm giữ kho khóa. Một lần nữa, khóa xác thực được lưu trữ trong một khe lưu trữ đã biết tại một địa chỉ đã biết, vì vậy đường dẫn có thể được mã hóa cứng.
Thật không may, Chứng minh trạng thái Ethereum rất phức tạp, nhưng tồn tại các thư viện để xác thực chúng và nếu bạn sử dụng các thư viện đó, thì cơ chế này không quá phức tạp để triển khai.
** Vấn đề lớn hơn là chi phí. ** Bằng chứng Merkle rất dài, thật không may, cây Patricia dài hơn ~3,9 lần so với mức cần thiết (chính xác là: bằng chứng Merkle lý tưởng cho một cây chứa N đối tượng dài 32 * log2(N) byte và bởi vì cây Patricia của Ethereum có 16 lá cho mỗi con và bằng chứng của những cây này dài 32 * 15 * log16(N) ~= 125 * log2(N) byte). Ở trạng thái có khoảng 250 triệu (~2²⁸) tài khoản, điều này làm cho mỗi bằng chứng 125 * 28 = 3500 byte hoặc khoảng 56.000 gas, cộng thêm chi phí giải mã và xác minh hàm băm.
Cùng với nhau, hai bằng chứng sẽ tiêu tốn khoảng 100.000 đến 150.000 gas (nếu được sử dụng cho mỗi giao dịch, không bao gồm xác minh chữ ký) - cao hơn nhiều so với giá cơ sở hiện tại là 21.000 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 nhiều so với L1. Mặt khác, dữ liệu phải được xuất bản lên L1. Vì vậy, sự so sánh không phải là gas 21k so với gas 15k; mà là gas L2 21k so với gas L1 100k.
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í gas L1 và chi phí gas L2:
Hiện tại, L1 đắt hơn 15-25 lần so với L2 đối với việc gửi đơn giản và đắt hơn 20-50 lần đối với các giao dịch hoán đổi mã thông báo. Gửi đơn giản là lượng dữ liệu tương đối lớn, nhưng lượng tính toán trao đổi lớn hơn nhiều. Do đó, hoán đổi là điểm chuẩn tốt hơn cho chi phí gần đúng của tính toán L1 so với tính toán L2. Khi tính đến tất cả những điều này, nếu chúng tôi giả định 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 50 giao dịch thông thường.
Tất nhiên, việc sử dụng cây Merkle nhị phân giúp giảm chi phí xuống ~4 lần, nhưng ngay cả khi đó, trong hầu hết các trường hợp, chi phí vẫn quá cao - nếu chúng tôi sẵn sàng hy sinh khả năng không còn tương thích với cây trạng thái lục giác hiện tại của Ethereum, chúng tôi sẽ tìm kiếm lựa chọn tốt hơn.
5. Bằng chứng ZK-SNARK sẽ 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 đó. Một ZK-SNARK yêu cầu ~400.000 GAS để tính toán, mất khoảng 400 byte (so với: một giao dịch cơ bản cần 21.000 gas và 100 byte, có thể giảm xuống còn ~25 từ sau khi nén trong Festival tương lai). Do đó, từ quan điểm tính toán, chi phí của ZK-SNARK gấp 19 lần chi phí của các giao dịch cơ bản ngày nay và từ quan điểm dữ liệu, chi phí của ZK-SNARK gấp 4 lần so với giao dịch cơ bản ngày nay và 16 lần chi phí của các lần giao dịch cơ bản trong tương lai.
Những con số đó là một cải tiến lớn so với bằng chứng của bà Merkel, nhưng chúng vẫn còn khá đắt. Có hai cách để cải thiện điều này: (i) bằng chứng KZG cho mục đích đặc biệt hoặc (ii) tổng hợp, tương tự như tổng hợp ERC-4337 nhưng sử dụng toán học phức tạp hơn. Chúng ta có thể học cả hai cùng một lúc.
6. Bằng chứng KZG chuyên dụng sẽ hoạt động như thế nào?
Cảnh báo, phần này thiên về toán học hơn những phần khác. Điều này là do chúng tôi đang vượt ra ngoài các công cụ có mục đích chung và xây dựng một số công cụ có mục đích đặc biệt rẻ hơn, vì vậy chúng tôi phải "chui" nhiều hơn. Nếu toán học sâu không phải là sở thích của bạn, hãy chuyển thẳng sang phần tiếp theo.
Đầu tiên, tóm tắt về cách thức hoạt động của các cam kết KZG:
Chúng ta có thể biểu diễn một tập hợp dữ liệu [D_1...D_n] bằng cách sử dụng bằng chứng KZG của một đa thức suy ra từ dữ liệu: cụ thể là đa thức P, trong đó P(w) = D_1, P(w²) = D _2 ... P(wⁿ) = D_n. w ở đây là "gốc đồng nhất", giá trị của wN = 1 đối với một số kích thước miền đánh giá N (tất cả điều này được thực hiện trong các trường hữu hạn).
Để "cam kết" với P, chúng ta tạo một điểm đường cong elip com(P) = P₀ * G + P₁ * S₁ + ... + Pk * Sk. đây:
-G là điểm tạo cho đường cong
-Pi là hệ số thứ i của đa thức P
-Si là điểm thứ i trong thiết lập đáng tin cậy
Để 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.
Để xác minh chứng minh, chúng tôi kiểm tra phương trình Q * (X - z) = P - a bằng cách thực hiện kiểm tra đường cong elip trên chứng minh com(Q) và cam kết đa thức com(P): chúng tôi kiểm tra e(com(Q) ), com( X - z)) ? = e(com(P) - com(a), com(1))
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
-com（P₁） + com（P₂） = com（P₁ + P₂）
Điều này cũng có nghĩa là bạn có thể "chỉnh sửa" giá trị thành 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 những 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ực tuyến, 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 cam kết KZG đối với bộ giá trị com(L_i) (hoặc hàm băm(com(L_i)), vì vậy, bất cứ khi nào ai đó cần Khi cập nhật cây trên chuỗi, họ có thể chỉ cần cung cấp bằng chứng về tính chính xác của mình cho com(L_i) thích hợp.
Vì vậy, chúng tôi có một cấu trúc nơi chúng tôi có thể tiếp tục thêm các giá trị vào cuối danh sách đang phát triển, mặc dù có một số giới hạn kích thước (trên thực tế, có thể thực hiện được hàng trăm triệu giá trị). Sau đó, chúng tôi sử dụng cấu trúc này làm cấu trúc dữ liệu của mình để quản lý (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 cam kết khóa L2, Được lưu trữ trên Ethereum L1 và được nhân đôi tới 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.
Do đó, một bằng chứng đầy đủ yêu cầu:
Kho khóa chứa com (danh sách khóa) mới nhất trên L2 (48 byte)
-KZG chứng minh rằng com(key list) là com(value in mirror_list), cam kết với tất cả các danh sách gửi key list (48 byte)
-KZG chứng minh rằng khóa của bạn nằm trong com (danh sách khóa) (48 byte, cộng với 4 byte cho chỉ mục)
Trên thực tế, có thể kết hợp hai bằng chứng KZG thành một, vì vậy chúng tôi có tổng kích thước chỉ 100 byte.
Lưu ý một điều tinh 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 các vị trí theo thứ tự. Hợp đồng cam kết khóa sẽ chứa sổ đăng ký nội bộ của chính nó, ánh xạ từng 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 (địa chỉ của kho khóa) thay vì chỉ khóa, để giao tiếp rõ ràng với các L2 khác mà kho khóa một mục cụ thể đang nói về.
Ưu điểm của kỹ thuật này là nó hoạt động rất tốt trên L2. Dữ liệu là 100 byte, ngắn hơn ~4 lần so với ZK-SNARK và ngắn hơn so với bằng chứng Merkle. Chi phí tính ra chủ yếu là 1 cặp séc măng, tức khoảng 119.000 tiền xăng. Trên L1, dữ liệu ít quan trọng hơn tính toán, vì vậy, thật không may, KZG đắt hơn một chút so với bằng chứng Merkle.
7. Cây Verkle sẽ hoạt động như thế nào?
Về cơ bản, cây Verkle liên quan đến việc sắp xếp các cam kết KZG (hoặc cam kết IPA, có thể hiệu quả hơn và sử dụng mã hóa đơn giản hơn): để lưu trữ các giá trị 2⁴⁸, bạn thực hiện cam kết KZG với danh sách các giá trị 2²⁴, mỗi giá trị chính là một Cam kết KZG đối với 2²⁴ Giá trị. Cây Verkle được xem xét mạnh mẽ cho cây trạng thái Ethereum, bởi vì cây Verkle có thể được sử dụng để giữ ánh xạ khóa-giá trị, không chỉ danh sách (về cơ bản, bạn có thể tạo cây có kích thước 2²⁵⁶ nhưng bắt đầu trống, chỉ khi bạn chỉ điền vào các phần cụ thể của tree khi bạn thực sự cần điền chúng).
Cây Vicker trông như thế nào. Trên thực tế, bạn có thể cung cấp cho mỗi nút chiều rộng là 256 == 2⁸ đối với cây dựa trên IPA và 2²⁴ đối với cây dựa trên KZG.
Bằng chứng trong cây Verkle dài hơn một chút so với trong KZG; chúng có thể dài hàng trăm byte. Chúng cũng khó xác minh, đặc biệt nếu bạn cố gắng tổng hợp nhiều bằng chứng thành một.
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 (vì chi phí dữ liệu thấp hơn) và SNARKing rẻ hơn (vì chi phí bằng chứng thấp hơn).
Ưu điểm lớn nhất của cây Verkle là chúng có thể phối hợp các cấu trúc dữ liệu: Bằng chứng Verkle có thể được sử dụng trực tiếp cho các trạng thái L1 hoặc L2, không có cấu trúc chồng chất và sử dụng chính xác cùng một cơ chế cho L1 và L2. Khi máy tính lượng tử trở thành một vấn đề hoặc khi phân nhánh Merkle chứng tỏ đủ hiệu quả, cây Verkle có thể được thay thế tại chỗ bằng cây băm nhị phân có hàm băm thân thiện với SNARK phù hợp.
8. Uẩn
Nếu N người dùng thực hiện N giao dịch (hoặc thực tế hơn là N ERC-4337 UserOperations) cần chứng minh N yêu cầu chuỗi chéo, chúng tôi có thể tiết kiệm rất nhiều tiền bằng cách tổng hợp các bằng chứng này: kết hợp các giao dịch này thành một khối hoặc Trình tạo gói mà đi vào khối có thể tạo ra một bằng chứng chứng minh tất cả các tuyên bố này cùng một lúc.
Điều này có thể có nghĩa là:
Bằng chứng ZK-SNARK cho N chi nhánh Merkle
Một KZG đa bằng chứng
Một Verkle multi-proof (hoặc ZK-SNARK đa-proof)
Cả ba trường hợp, mỗi bằng chứng chỉ cần vài trăm nghìn tiền xăng. Người xây dựng cần tạo một trong số này trên mỗi L2 cho người dùng trong L2 đó; do đó, để dễ xây dựng, toàn bộ sơ đồ cần được sử dụng đủ để thường có ít nhất một vài giao dịch trong cùng một khối trên nhiều giao dịch L2 chính .
Nếu sử dụng ZK-SNARK, chi phí cận biên chính chỉ là "logic kinh doanh" của việc chuyển số giữa các hợp đồng, vì vậy mỗi người dùng có thể cần vài nghìn L2 khí. Nếu sử dụng đa bằng chứng KZG, người chuẩn bị cần thêm 48 gas cho mỗi kho khóa chứa L2 được sử dụng trong khối, do đó, chi phí cận biên của sơ đồ trên mỗi người dùng sẽ là trên mỗi L2 (không phải trên mỗi người dùng) và sau đó Đã thêm ~800 L1 gas . Nhưng 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 khí L1 và hàng trăm nghìn khí L2 cho mỗi người dùng. Đối với cây Verkle, bạn có thể sử dụng trực tiếp đa bằng chứng của Verkle, thêm khoảng 100-200 byte cho mỗi người dùng hoặc bạn có thể tạo ZK-SNARK của Verkle đa bằng chứng, chi phí tương tự như ZK-SNARK của nhánh Merkle, nhưng bằng chứng chi phí thấp hơn nhiều.
Từ quan điểm triển khai, tốt hơn là các trình đóng gói nên 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ế để các nhà xây dựng tổng hợp các phần hành động của người dùng theo cách tùy chỉnh. Thậm chí còn có triển khai tập hợp chữ ký BLS, có thể giảm chi phí gas trên L2 theo hệ số từ 1,5 đến 3, tùy thuộc vào các dạng nén khác được bao gồm.
Sơ đồ từ bài đăng triển khai ví BLS hiển thị quy trình làm việc cho chữ ký tổng hợp BLS trong phiên bản đầu tiên của ERC-4337. Quy trình tổng hợp các bằng chứng xuyên chuỗi có thể trông rất giống nhau.
9. Đọc trạng thái trực tiếp
Khả năng cuối cùng, cũng chỉ khả dụng đối với 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 lệnh gọi tĩnh tới các hợp đồng trên L1.
Điều này có thể được thực hiện với opcodes hoặc biên dịch trước, cho phép gọi đến L1, nơi bạn cung cấp địa chỉ đích, gas và calldata, và nó trả về đầu ra, nhưng vì các lệnh 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 rằng L1 đã xử lý khoản tiền gửi, vì vậy không có gì ngăn cản điều đó được thực hiện; đây chủ yếu là một thách thức triển khai kỹ thuật (xem: điều này từ một RFP lạc quan để hỗ trợ các lệnh gọi tĩnh tới L1).
Lưu ý rằng nếu kho khóa nằm trên L1 và L2 tích hợp các cuộc gọi tĩnh L1, thì không cần bằng chứng nào cả! Tuy nhiên, nếu L2 không tích hợp các cuộc gọi tĩnh L1 hoặc nếu kho khóa nằm trên L2 (điều này cuối cùng có thể phải được thực hiện khi L1 trở nên quá đắt để người dùng sử dụng dù chỉ một chút), thì sẽ cần phải có bằng chứng.
10. 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. May mắn thay, tất cả các L2 đã có một số chức năng để truy cập trạng thái L1 mới nhất. Điều này là do họ cần chức năng như vậy để xử lý các tin nhắn từ L1 đến L2, đặc biệt là tiền gửi.
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à chuyển nó tới L2 dưới dạng tin nhắn gửi tiền . 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:
Nếu L2 triển khai chức năng "đọc trực tiếp L1" theo cách lười biếng, chỉ đọc gốc trạng thái L1 cuối cùng, thì độ trễ thường là 15 phút, nhưng trong trường hợp nghiêm trọng xảy ra rò rỉ do không hoạt động (mà bạn phải chịu đựng), độ trễ có thể là tuần.
L2 chắc chắn có thể được thiết kế để đọc các gốc trạng thái L1 được cập nhật, nhưng vì L1 có thể khôi phục (điều này xảy ra trong quá trình rò rỉ không hoạt động ngay cả với tính cuối cùng của ổ cắm đơn), nên L2 cũng cần có khả năng khôi phục. Từ quan điểm kỹ thuật phần mềm, đây là một thách thức về mặt kỹ thuật, nhưng ít nhất Lạc quan có khả năng.
Nếu bạn sử dụng cầu gửi tiền để đưa gốc trạng thái L1 vào L2, thì kinh tế học đơn giản có thể cần một khoảng thời gian dài giữa các lần cập nhật tiền gửi: nếu toàn bộ chi phí của một khoản tiền gửi là 100.000 gas, hãy giả sử $1800 bằng ETH và phí 200 gwei, và các gốc L1 vào L2 mỗi ngày một lần, điều này sẽ tốn 236 USD mỗi L mỗi ngày hoặc 13.148 USD mỗi L2 mỗi năm để duy trì hệ thống. Một giờ chậm trễ tiêu tốn một khoản khổng lồ $315,569 mỗi L2 mỗi năm. Tốt nhất, luôn có một dòng người dùng giàu có thiếu kiên nhẫn trả tiền để cập nhật và giữ cho hệ thống được cập nhật cho những người khác. Tệ nhất, một số diễn viên vị tha sẽ phải tự trả giá cho điều đó.
"Oracles" (ít nhất là công nghệ mà một số người DeFi gọi là "oracles") không phải là một giải pháp có thể chấp nhận được ở đây: quản lý khóa ví là một chức năng cấp thấp rất quan trọng về bảo mật, vì vậy nó chỉ phụ thuộc tối đa vào một số A rất đơn giản, cơ sở hạ tầng cấp thấp không yêu cầu sự tin cậy về mật mã.
Ngoài ra, theo hướng ngược lại (L1 đọc là L2):
Trong Tập hợp lạc quan, trạng thái gốc mất một tuần để đạt đến L1 do sự chậm trễ trong việc chứng minh gian lận. Trong các bản tổng hợp ZK, hiện tại phải mất hàng giờ do sự kết hợp giữa thời gian xác minh và các hạn chế về kinh tế, mặc dù công nghệ trong tương lai sẽ giảm bớt điều này.
Xác nhận trước (từ trình sắp xếp thứ tự, người xác nhận, v.v.) không phải là giải pháp chấp nhận được đối với L1 đọc L2. Quản lý ví là một chức năng cấp thấp rất quan trọng về bảo mật, vì vậy mức độ bảo mật của giao tiếp L2 - L1 phải là tuyệt đối: thậm chí không thể đẩy sai gốc trạng thái L1 bằng cách chiếm lấy bộ trình xác thực L2. Trạng thái gốc duy nhất mà L1 nên tin tưởng là trạng thái đã được chấp nhận làm gốc trạng thái cuối cùng bởi hợp đồng nắm giữ trạng thái gốc của L2 trên L1.
Đối với nhiều trường hợp sử dụng DeFi, 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 đáng tin cậy; đối với những trường hợp này, bạn thực sự cần cầu nối nhanh hơn với các mô hình bảo mật không hoàn hảo hơn. Tuy nhiên, đối với trường hợp sử dụng cập nhật khóa ví, thời gian trì hoãn lâu hơn có thể chấp nhận được hơn: thay vì trì hoãn giao dịch trong nhiều giờ, bạn trì hoãn thay đổi khóa. Bạn chỉ cần giữ chìa khóa cũ lâu hơn. Nếu bạn thay đổi khóa của mình vì nó đã bị đánh cắp, bạn sẽ có một lỗ hổng trong một thời gian dài, 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. Các 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 để chúng có thể nhanh chóng được cam kết với L1.
Các khối của chuỗi L2 có thể không chỉ phụ thuộc vào các khối L2 trước đó mà còn phụ thuộc vào các khối L1. Nếu L1 phục hồi qua một liên kết như vậy, L2 cũng sẽ phục hồi. Cần lưu ý rằng đây cũng là cách mà các phiên bản sharding trước đó (trước Dank) được hình dung sẽ hoạt động; xem tại đây để biết mã.
11. Một chuỗi khác cần bao nhiêu kết nối với Ethereum để giữ một kho khóa bắt nguồn từ 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 bản tổng hợp: nếu đó là L3 hoặc xác thực, bạn có thể giữ một chiếc ví ở đó, miễn là bạn giữ kho khóa trên một bản tổng hợp L1 hoặc ZK. Những gì bạn thực sự cần là chuỗi có quyền truy cập trực tiếp vào gốc trạng thái Ethereum và cam kết kỹ thuật và xã hội sẵn sàng tổ chức lại nếu Ethereum tổ chức lại và hard fork nếu Ethereum hard fork.
Một câu hỏi nghiên cứu thú vị là xác định mức độ mà một chuỗi có thể có hình thức kết nối này với nhiều chuỗi khác (ví dụ: Ethereum và Zcash). Có thể làm điều này một cách ngây thơ: nếu Ethereum hoặc Zcash tổ chức lại, chuỗi của bạn có thể đồng ý tổ chức lại (và hard fork nếu Ethereum hoặc Zcash hard fork), nhưng các nhà khai thác nút và cộng đồng của bạn thường có hai lần phụ thuộc vào công nghệ và chính trị. Do đó, kỹ thuật này có thể được sử dụng để kết nối với một số chuỗi khác, nhưng với chi phí tăng lên. Các kế hoạch dựa trên cầu nối ZK có các đặc tính kỹ thuật hấp dẫn, nhưng điểm yếu chính của chúng là chúng không mạnh mẽ trước các cuộc tấn công 51% hoặc các nhánh cứng. Cũng có thể có những giải pháp thông minh hơn.
12. Bảo vệ quyền riêng tư
Lý tưởng nhất, chúng tôi cũng muốn bảo vệ quyền riêng tư. Nếu bạn có nhiều ví được quản lý bởi cùng một kho khóa, thì chúng tôi muốn đảm bảo rằng:
Không rõ ràng rằng tất cả các ví này đều được kết nối với nhau.
Người bảo vệ phục hồi chức năng xã hội không biết họ đang bảo vệ địa chỉ nào.
Điều này tạo ra một số vấn đề:
Chúng tôi không thể sử dụng bằng chứng Merkle trực tiếp vì chúng không bảo vệ quyền riêng tư.
Nếu chúng tôi sử dụng KZG hoặc SNARK, thì bằng chứng cần cung cấp phiên bản ẩn của khóa xác minh mà không tiết lộ vị trí của khóa xác minh.
Nếu chúng ta sử dụng tập hợp, thì tập hợp sẽ không tìm hiểu các vị trí trong bản rõ, thay vào đó, tập hợp sẽ nhận được các bằng chứng mù và có cách để tổng hợp các bằng chứng này.
Chúng tôi không thể sử dụng "phiên bản nhẹ" (gia hạn khóa chỉ sử dụng bằng chứng chuỗi chéo), vì nó tạo ra rò rỉ quyền riêng tư: nếu nhiều ví được cập nhật cùng lúc do quá trình cập nhật, thời gian sẽ rò rỉ thông tin có thể liên quan đến những chiếc ví này.
Do đó, chúng tôi phải sử dụng "phiên bản nặng" (bằng chứng chuỗi chéo của mỗi giao dịch).
Với SNARK, giải pháp rất đơn giản về mặt khái niệm: theo mặc định, bằng chứng bị ẩn thông tin và bộ tổng hợp cần tạo SNARK đệ quy để chứng minh SNARK.
Thách thức chính với phương pháp này hiện tại là việc tổng hợp yêu cầu trình tổng hợp tạo một SNARK đệ quy, hiện đang rất chậm.
Với KZG, chúng ta có thể sử dụng tác phẩm này (xem thêm: phiên bản chính thức hơn của tác phẩm này trong bài báo Caulk) về các bằng chứng KZG tiết lộ không được lập chỉ mục làm điểm khởi đầu. Tuy nhiên, tổng hợp các bằng chứng mù quáng là một vấn đề mở cần được chú ý nhiều hơn.
Thật không may, đọc L1 trực tiếp từ bên trong L2 không bảo vệ quyền riêng tư, mặc dù việc triển khai chức năng đọc trực tiếp vẫn rất hữu ích, để giảm thiểu độ trễ và vì tiện ích của nó cho các ứng dụng khác.
13. Tóm tắt
Để có ví phục hồi mạng xã hội liên chuỗi, quy trình làm việc thực tế nhất là ví duy trì kho khóa ở một vị trí và ví duy trì ví ở nhiều vị trí, nơi ví đọc kho khóa để (i) cập nhật khóa xác thực cục bộ xem, hoặc (ii) trong quá trình xác thực từng giao dịch.
Một yếu tố quan trọng giúp điều này trở nên khả thi là bằng chứng xuyên chuỗi. Chúng ta cần làm việc để tối ưu hóa những bằng chứng này. ZK-SNARK hoặc các giải pháp KZG tùy chỉnh đang chờ bằng chứng của Verkle dường như là những lựa chọn tốt nhất.
Về lâu dài, một giao thức tổng hợp (trong đó các gói tạo bằng chứng tổng hợp như một phần của việc tạo gói tất cả các hành động của người dùng do người dùng gửi) là cần thiết để giảm thiểu chi phí. Điều này có lẽ nên được tích hợp vào hệ sinh thái ERC-4337, mặc dù có thể cần phải thay đổi ERC-4337.
L2 phải được tối ưu hóa để giảm thiểu độ trễ khi đọc trạng thái L1 (hoặc ít nhất là trạng thái gốc) từ bên trong L2. Lý tưởng nhất là các L2 có thể đọc trực tiếp trạng thái L1, tiết kiệm không gian bằng chứng.
Ví không chỉ có thể có trên L2; bạn cũng có thể đặt ví trên các hệ thống có mức kết nối thấp hơn với Ethereum (L3 hoặc thậm chí chỉ cần đồng ý bao gồm gốc trạng thái Ethereum và chuỗi nhánh độc lập).
Tuy nhiên, kho khóa phải ở trên L1 hoặc ZK rollup bảo mật cao L2. Sử dụng L1 giúp tiết kiệm rất nhiều sự phức tạp, nhưng thậm chí điều đó có thể quá tốn kém trong thời gian dài, vì vậy cần sử dụng kho khóa trên L2.
Việc bảo vệ quyền riêng tư sẽ đòi hỏi nhiều công việc hơn và khiến một số lựa chọn trở nên khó khăn hơn. Nhưng có lẽ chúng ta nên chuyển sang các giải pháp bảo vệ quyền riêng tư, ít nhất là đảm bảo rằng bất cứ điều gì chúng tôi nghĩ ra đều tương thích với việc bảo vệ quyền riêng tư.
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Buterin: Thông tin chi tiết về các lần đọc L2 chéo cho ví và các trường hợp sử dụng khác
Tác giả: Vitalik Buterin Biên dịch: Vernacular Blockchain
Trong bài viết trước của tôi về ba ca làm việc, tôi đã nêu ra một số lý do chính tại sao việc bắt đầu suy nghĩ rõ ràng về hỗ trợ L1 + chéo L2, bảo mật ví và quyền riêng tư là rất có giá trị vì các tính năng cơ bản cần thiết của ngăn xếp hệ sinh thái Mọi thứ được xây dựng dưới dạng plugin có thể được thiết kế riêng bởi một ví duy nhất.
Bài đăng này sẽ tập trung trực tiếp hơn vào các khía cạnh kỹ thuật của một bài toán con cụ thể, chẳng hạn như: cách đọc L1 dễ dàng hơn từ L2, L2 từ L1 hoặc L2 từ L2 khác. Giải quyết vấn đề này là rất quan trọng để kích hoạt kiến trúc phân tách nội dung/kho khóa, nhưng nó cũng có các trường hợp sử dụng có giá trị trong các lĩnh vực khác, đáng chú ý nhất là tối ưu hóa các chuỗi cuộc gọi chéo L2 đáng tin cậy, bao gồm các trường hợp sử dụng như di chuyển nội dung giữa L1 và L2 . ** Danh mục bài viết này ** Mục tiêu là gì? Bằng chứng chuỗi chéo trông như thế nào? Chúng ta có thể sử dụng loại sơ đồ chứng minh nào? Bằng chứng Merkle ZK SNARK Giấy chứng nhận KZG chuyên dụng Bằng chứng cây Verkle trùng hợp đọc trạng thái trực tiếp Làm cách nào để L2 tìm hiểu gốc trạng thái Ethereum gần đây nhất? Ví trên chuỗi không phải L2 bảo vệ quyền riêng tư tóm tắt
1. Mục tiêu là gì?
Sau khi L2 trở thành xu hướng chủ đạo, người dùng sẽ sở hữu tài sản trên nhiều L2 và có thể cả L1 nữa. Sau khi ví hợp đồng thông minh (đa chữ ký, khôi phục xã hội hoặc cách khác) trở thành xu hướng chủ đạo, các khóa cần thiết để truy cập một số tài khoản nhất định sẽ thay đổi theo thời gian và các khóa cũ hơn sẽ không còn hợp lệ nữa. Một khi hai điều đó xảy ra, người dùng sẽ cần một cách để thay đổi các khóa có quyền truy cập vào nhiều tài khoản ở nhiều nơi khác nhau mà không thực hiện một số lượng giao dịch cực lớn. Cụ thể, chúng tôi cần một cách để xử lý các địa chỉ phản thực: 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ữ tiền một cách an toàn. Tất cả chúng ta đều dựa vào các địa chỉ phản thực: khi bạn sử dụng Ethereum lần đầu tiên, bạn có thể tạo địa chỉ ETH mà ai đó có thể sử dụng để thanh toán cho bạn mà không cần "đăng ký" địa chỉ trên chuỗi (điều này yêu cầu trả phí txfee, vì vậy hãy giữ một số ETH). Đối với EOA, tất cả các địa chỉ đều bắt đầu bằng một địa chỉ phản thực. Với ví hợp đồng thông minh, các địa chỉ phản thực vẫn có thể thực hiện được phần lớn nhờ vào CREATE2, cho phép bạn có một địa chỉ ETH mà chỉ hợp đồng thông minh mới có thể điền vào bằng mã khớ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, ví hợp đồng thông minh đưa ra một thách thức mới: khả năng thay đổi khóa truy cập. Địa chỉ này là mã băm của mã khởi tạo và chỉ có thể chứa khóa xác minh ban đầu của 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 lan truyền một cách kỳ diệu đến các L2 khác. Nếu người dùng có nhiều địa chỉ trên nhiều L2, bao gồm cả các địa chỉ mà họ đang sử dụng trên L2 mà họ không biết (vì chúng không có thực), thì dường như chỉ có một cách để cho phép người dùng thay đổi khóa của họ: kiến trúc phân tách tài sản/kho khóa. Mỗi người dùng có (i) một "hợp đồng lưu trữ khóa" (trên L1 hoặc một 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í" đọc trên các chuỗi để tìm khóa xác minh.
Có hai cách để đạt được điều này:
Phiên bản nhẹ (chỉ kiểm tra các khóa được cập nhật): Mỗi ví lưu trữ khóa xác minh cục bộ và chứa một chức năng có thể được gọi để 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 khóa xác minh được lưu trữ cục bộ của nó cho phù hợp. Khi ví được sử dụng lần đầu tiên trên một L2 cụ thể, chức năng này phải được gọi để lấy khóa xác thực hiện tại từ kho khóa. -Ưu điểm: Bằng chứng xuyên chuỗi được sử dụng ít, vì vậy không thành vấn đề nếu bằng chứng xuyên chuỗi đắt tiền. Tất cả tiền chỉ có thể được sử dụng với khóa hiện tại, vì vậy nó vẫn an toàn.
2. Bằng chứng chuỗi chéo trông như thế nào?
Để chứng minh sự phức tạp đầy đủ, chúng ta sẽ khám phá trường hợp khó khăn nhất: kho khóa trên một L2, ví trên một L2 khác. Chỉ cần một nửa thiết kế này nếu kho khóa trên ví nằm trên L1.
Giả sử kho khóa nằm trên Linea và ví nằm trên Kakarot. Bằng chứng đầy đủ về khóa ví bao gồm:
3. Chúng ta có thể sử dụng những loại sơ đồ chứng minh nào?
Có năm lựa chọn chính: -Bằng chứng Merkle -Chung ZK-SNARK
"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 kết hợp tất cả các bằng chứng. Điều này có thể thực hiện được với SNARK và KZG, nhưng không phải với Merkle fork (bạn có thể kết hợp Merkle fork một chút, nhưng nó chỉ giúp bạn tiết kiệm nhật ký (txs trên mỗi khối)/log (tổng số kho khóa), trên thực tế, có thể là 15-30% ở giữa, vì vậy nó có thể không đáng giá). Việc tổng hợp chỉ trở nên có giá trị khi kịch bản có số lượng người dùng lớn, do đó, trong thực tế, việc triển khai phiên bản 1 có thể bỏ qua việc tổng hợp và triển khai nó trong phiên bản 2.
4. Bằng chứng Merkle sẽ hoạt động như thế nào?
Điều này rất dễ dàng: chỉ cần làm theo sơ đồ trong phần trước. Chính xác hơn, mỗi "bằng chứng" (giả sử trường hợp chứng minh độ khó tối đa của L2 này với L2 khác) sẽ chứa: Một nhánh Merkle chứng thực trạng thái gốc của L2 đang nắm giữ kho khóa, với trạng thái gốc mới nhất của Ethereum mà L2 biết đến. Kho khóa chứa gốc trạng thái của L2 được lưu trữ trong một khe lưu trữ đã biết tại một địa chỉ đã biết (hợp đồng trên L1 đại diện cho L2), vì vậy đường dẫn qua cây có thể được mã hóa cứng. Nhánh Merkle chứng thực khóa xác minh hiện tại, với gốc trạng thái của L2 đang nắm giữ kho khóa. Một lần nữa, khóa xác thực được lưu trữ trong một khe lưu trữ đã biết tại một địa chỉ đã biết, vì vậy đường dẫn có thể được mã hóa cứng. Thật không may, Chứng minh trạng thái Ethereum rất phức tạp, nhưng tồn tại các thư viện để xác thực chúng và nếu bạn sử dụng các thư viện đó, thì cơ chế này không quá phức tạp để triển khai. ** Vấn đề lớn hơn là chi phí. ** Bằng chứng Merkle rất dài, thật không may, cây Patricia dài hơn ~3,9 lần so với mức cần thiết (chính xác là: bằng chứng Merkle lý tưởng cho một cây chứa N đối tượng dài 32 * log2(N) byte và bởi vì cây Patricia của Ethereum có 16 lá cho mỗi con và bằng chứng của những cây này dài 32 * 15 * log16(N) ~= 125 * log2(N) byte). Ở trạng thái có khoảng 250 triệu (~2²⁸) tài khoản, điều này làm cho mỗi bằng chứng 125 * 28 = 3500 byte hoặc khoảng 56.000 gas, cộng thêm chi phí giải mã và xác minh hàm băm. Cùng với nhau, hai bằng chứng sẽ tiêu tốn khoảng 100.000 đến 150.000 gas (nếu được sử dụng cho mỗi giao dịch, không bao gồm xác minh chữ ký) - cao hơn nhiều so với giá cơ sở hiện tại là 21.000 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 nhiều so với L1. Mặt khác, dữ liệu phải được xuất bản lên L1. Vì vậy, sự so sánh không phải là gas 21k so với gas 15k; mà là gas L2 21k so với gas L1 100k. 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í gas L1 và chi phí gas L2:
Hiện tại, L1 đắt hơn 15-25 lần so với L2 đối với việc gửi đơn giản và đắt hơn 20-50 lần đối với các giao dịch hoán đổi mã thông báo. Gửi đơn giản là lượng dữ liệu tương đối lớn, nhưng lượng tính toán trao đổi lớn hơn nhiều. Do đó, hoán đổi là điểm chuẩn tốt hơn cho chi phí gần đúng của tính toán L1 so với tính toán L2. Khi tính đến tất cả những điều này, nếu chúng tôi giả định 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 50 giao dịch thông thường. Tất nhiên, việc sử dụng cây Merkle nhị phân giúp giảm chi phí xuống ~4 lần, nhưng ngay cả khi đó, trong hầu hết các trường hợp, chi phí vẫn quá cao - nếu chúng tôi sẵn sàng hy sinh khả năng không còn tương thích với cây trạng thái lục giác hiện tại của Ethereum, chúng tôi sẽ tìm kiếm lựa chọn tốt hơn.
5. Bằng chứng ZK-SNARK sẽ 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 đó. Một ZK-SNARK yêu cầu ~400.000 GAS để tính toán, mất khoảng 400 byte (so với: một giao dịch cơ bản cần 21.000 gas và 100 byte, có thể giảm xuống còn ~25 từ sau khi nén trong Festival tương lai). Do đó, từ quan điểm tính toán, chi phí của ZK-SNARK gấp 19 lần chi phí của các giao dịch cơ bản ngày nay và từ quan điểm dữ liệu, chi phí của ZK-SNARK gấp 4 lần so với giao dịch cơ bản ngày nay và 16 lần chi phí của các lần giao dịch cơ bản trong tương lai. Những con số đó là một cải tiến lớn so với bằng chứng của bà Merkel, nhưng chúng vẫn còn khá đắt. Có hai cách để cải thiện điều này: (i) bằng chứng KZG cho mục đích đặc biệt hoặc (ii) tổng hợp, tương tự như tổng hợp ERC-4337 nhưng sử dụng toán học phức tạp hơn. Chúng ta có thể học cả hai cùng một lúc.
6. Bằng chứng KZG chuyên dụng sẽ hoạt động như thế nào?
Cảnh báo, phần này thiên về toán học hơn những phần khác. Điều này là do chúng tôi đang vượt ra ngoài các công cụ có mục đích chung và xây dựng một số công cụ có mục đích đặc biệt rẻ hơn, vì vậy chúng tôi phải "chui" nhiều hơn. Nếu toán học sâu không phải là sở thích của bạn, hãy chuyển thẳng sang phần tiếp theo. Đầu tiên, tóm tắt về cách thức hoạt động của các cam kết KZG: Chúng ta có thể biểu diễn một tập hợp dữ liệu [D_1...D_n] bằng cách sử dụng bằng chứng KZG của một đa thức suy ra từ dữ liệu: cụ thể là đa thức P, trong đó P(w) = D_1, P(w²) = D _2 ... P(wⁿ) = D_n. w ở đây là "gốc đồng nhất", giá trị của wN = 1 đối với một số kích thước miền đánh giá N (tất cả điều này được thực hiện trong các trường hữu hạn). Để "cam kết" với P, chúng ta tạo một điểm đường cong elip com(P) = P₀ * G + P₁ * S₁ + ... + Pk * Sk. đây: -G là điểm tạo cho đường cong -Pi là hệ số thứ i của đa thức P -Si là điểm thứ i trong thiết lập đáng tin cậy Để 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. Để xác minh chứng minh, chúng tôi kiểm tra phương trình Q * (X - z) = P - a bằng cách thực hiện kiểm tra đường cong elip trên chứng minh com(Q) và cam kết đa thức com(P): chúng tôi kiểm tra e(com(Q) ), com( X - z)) ? = e(com(P) - com(a), com(1)) Một số thuộc tính chính cần biết bao gồm:
Do đó, một bằng chứng đầy đủ yêu cầu:
7. Cây Verkle sẽ hoạt động như thế nào?
Về cơ bản, cây Verkle liên quan đến việc sắp xếp các cam kết KZG (hoặc cam kết IPA, có thể hiệu quả hơn và sử dụng mã hóa đơn giản hơn): để lưu trữ các giá trị 2⁴⁸, bạn thực hiện cam kết KZG với danh sách các giá trị 2²⁴, mỗi giá trị chính là một Cam kết KZG đối với 2²⁴ Giá trị. Cây Verkle được xem xét mạnh mẽ cho cây trạng thái Ethereum, bởi vì cây Verkle có thể được sử dụng để giữ ánh xạ khóa-giá trị, không chỉ danh sách (về cơ bản, bạn có thể tạo cây có kích thước 2²⁵⁶ nhưng bắt đầu trống, chỉ khi bạn chỉ điền vào các phần cụ thể của tree khi bạn thực sự cần điền chúng).
Cây Vicker trông như thế nào. Trên thực tế, bạn có thể cung cấp cho mỗi nút chiều rộng là 256 == 2⁸ đối với cây dựa trên IPA và 2²⁴ đối với cây dựa trên KZG. Bằng chứng trong cây Verkle dài hơn một chút so với trong KZG; chúng có thể dài hàng trăm byte. Chúng cũng khó xác minh, đặc biệt nếu bạn cố gắng tổng hợp nhiều bằng chứng thành một. 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 (vì chi phí dữ liệu thấp hơn) và SNARKing rẻ hơn (vì chi phí bằng chứng thấp hơn). Ưu điểm lớn nhất của cây Verkle là chúng có thể phối hợp các cấu trúc dữ liệu: Bằng chứng Verkle có thể được sử dụng trực tiếp cho các trạng thái L1 hoặc L2, không có cấu trúc chồng chất và sử dụng chính xác cùng một cơ chế cho L1 và L2. Khi máy tính lượng tử trở thành một vấn đề hoặc khi phân nhánh Merkle chứng tỏ đủ hiệu quả, cây Verkle có thể được thay thế tại chỗ bằng cây băm nhị phân có hàm băm thân thiện với SNARK phù hợp.
8. Uẩn
Nếu N người dùng thực hiện N giao dịch (hoặc thực tế hơn là N ERC-4337 UserOperations) cần chứng minh N yêu cầu chuỗi chéo, chúng tôi có thể tiết kiệm rất nhiều tiền bằng cách tổng hợp các bằng chứng này: kết hợp các giao dịch này thành một khối hoặc Trình tạo gói mà đi vào khối có thể tạo ra một bằng chứng chứng minh tất cả các tuyên bố này cùng một lúc. Điều này có thể có nghĩa là:
Sơ đồ từ bài đăng triển khai ví BLS hiển thị quy trình làm việc cho chữ ký tổng hợp BLS trong phiên bản đầu tiên của ERC-4337. Quy trình tổng hợp các bằng chứng xuyên chuỗi có thể trông rất giống nhau.
9. Đọc trạng thái trực tiếp
Khả năng cuối cùng, cũng chỉ khả dụng đối với 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 lệnh gọi tĩnh tới các hợp đồng trên L1. Điều này có thể được thực hiện với opcodes hoặc biên dịch trước, cho phép gọi đến L1, nơi bạn cung cấp địa chỉ đích, gas và calldata, và nó trả về đầu ra, nhưng vì các lệnh 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 rằng L1 đã xử lý khoản tiền gửi, vì vậy không có gì ngăn cản điều đó được thực hiện; đây chủ yếu là một thách thức triển khai kỹ thuật (xem: điều này từ một RFP lạc quan để hỗ trợ các lệnh gọi tĩnh tới L1). Lưu ý rằng nếu kho khóa nằm trên L1 và L2 tích hợp các cuộc gọi tĩnh L1, thì không cần bằng chứng nào cả! Tuy nhiên, nếu L2 không tích hợp các cuộc gọi tĩnh L1 hoặc nếu kho khóa nằm trên L2 (điều này cuối cùng có thể phải được thực hiện khi L1 trở nên quá đắt để người dùng sử dụng dù chỉ một chút), thì sẽ cần phải có bằng chứng.
10. 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. May mắn thay, tất cả các L2 đã có một số chức năng để truy cập trạng thái L1 mới nhất. Điều này là do họ cần chức năng như vậy để xử lý các tin nhắn từ L1 đến L2, đặc biệt là tiền gửi. 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à chuyển nó tới L2 dưới dạng tin nhắn gửi tiền . 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:
Các khối của chuỗi L2 có thể không chỉ phụ thuộc vào các khối L2 trước đó mà còn phụ thuộc vào các khối L1. Nếu L1 phục hồi qua một liên kết như vậy, L2 cũng sẽ phục hồi. Cần lưu ý rằng đây cũng là cách mà các phiên bản sharding trước đó (trước Dank) được hình dung sẽ hoạt động; xem tại đây để biết mã.
11. Một chuỗi khác cần bao nhiêu kết nối với Ethereum để giữ một kho khóa bắt nguồn từ 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 bản tổng hợp: nếu đó là L3 hoặc xác thực, bạn có thể giữ một chiếc ví ở đó, miễn là bạn giữ kho khóa trên một bản tổng hợp L1 hoặc ZK. Những gì bạn thực sự cần là chuỗi có quyền truy cập trực tiếp vào gốc trạng thái Ethereum và cam kết kỹ thuật và xã hội sẵn sàng tổ chức lại nếu Ethereum tổ chức lại và hard fork nếu Ethereum hard fork. Một câu hỏi nghiên cứu thú vị là xác định mức độ mà một chuỗi có thể có hình thức kết nối này với nhiều chuỗi khác (ví dụ: Ethereum và Zcash). Có thể làm điều này một cách ngây thơ: nếu Ethereum hoặc Zcash tổ chức lại, chuỗi của bạn có thể đồng ý tổ chức lại (và hard fork nếu Ethereum hoặc Zcash hard fork), nhưng các nhà khai thác nút và cộng đồng của bạn thường có hai lần phụ thuộc vào công nghệ và chính trị. Do đó, kỹ thuật này có thể được sử dụng để kết nối với một số chuỗi khác, nhưng với chi phí tăng lên. Các kế hoạch dựa trên cầu nối ZK có các đặc tính kỹ thuật hấp dẫn, nhưng điểm yếu chính của chúng là chúng không mạnh mẽ trước các cuộc tấn công 51% hoặc các nhánh cứng. Cũng có thể có những giải pháp thông minh hơn.
12. Bảo vệ quyền riêng tư
Lý tưởng nhất, chúng tôi cũng muốn bảo vệ quyền riêng tư. Nếu bạn có nhiều ví được quản lý bởi cùng một kho khóa, thì chúng tôi muốn đảm bảo rằng:
Thách thức chính với phương pháp này hiện tại là việc tổng hợp yêu cầu trình tổng hợp tạo một SNARK đệ quy, hiện đang rất chậm. Với KZG, chúng ta có thể sử dụng tác phẩm này (xem thêm: phiên bản chính thức hơn của tác phẩm này trong bài báo Caulk) về các bằng chứng KZG tiết lộ không được lập chỉ mục làm điểm khởi đầu. Tuy nhiên, tổng hợp các bằng chứng mù quáng là một vấn đề mở cần được chú ý nhiều hơn. Thật không may, đọc L1 trực tiếp từ bên trong L2 không bảo vệ quyền riêng tư, mặc dù việc triển khai chức năng đọc trực tiếp vẫn rất hữu ích, để giảm thiểu độ trễ và vì tiện ích của nó cho các ứng dụng khác.
13. Tóm tắt
Để có ví phục hồi mạng xã hội liên chuỗi, quy trình làm việc thực tế nhất là ví duy trì kho khóa ở một vị trí và ví duy trì ví ở nhiều vị trí, nơi ví đọc kho khóa để (i) cập nhật khóa xác thực cục bộ xem, hoặc (ii) trong quá trình xác thực từng giao dịch. Một yếu tố quan trọng giúp điều này trở nên khả thi là bằng chứng xuyên chuỗi. Chúng ta cần làm việc để tối ưu hóa những bằng chứng này. ZK-SNARK hoặc các giải pháp KZG tùy chỉnh đang chờ bằng chứng của Verkle dường như là những lựa chọn tốt nhất. Về lâu dài, một giao thức tổng hợp (trong đó các gói tạo bằng chứng tổng hợp như một phần của việc tạo gói tất cả các hành động của người dùng do người dùng gửi) là cần thiết để giảm thiểu chi phí. Điều này có lẽ nên được tích hợp vào hệ sinh thái ERC-4337, mặc dù có thể cần phải thay đổi ERC-4337. L2 phải được tối ưu hóa để giảm thiểu độ trễ khi đọc trạng thái L1 (hoặc ít nhất là trạng thái gốc) từ bên trong L2. Lý tưởng nhất là các L2 có thể đọc trực tiếp trạng thái L1, tiết kiệm không gian bằng chứng. Ví không chỉ có thể có trên L2; bạn cũng có thể đặt ví trên các hệ thống có mức kết nối thấp hơn với Ethereum (L3 hoặc thậm chí chỉ cần đồng ý bao gồm gốc trạng thái Ethereum và chuỗi nhánh độc lập). Tuy nhiên, kho khóa phải ở trên L1 hoặc ZK rollup bảo mật cao L2. Sử dụng L1 giúp tiết kiệm rất nhiều sự phức tạp, nhưng thậm chí điều đó có thể quá tốn kém trong thời gian dài, vì vậy cần sử dụng kho khóa trên L2. Việc bảo vệ quyền riêng tư sẽ đòi hỏi nhiều công việc hơn và khiến một số lựa chọn trở nên khó khăn hơn. Nhưng có lẽ chúng ta nên chuyển sang các giải pháp bảo vệ quyền riêng tư, ít nhất là đảm bảo rằng bất cứ điều gì chúng tôi nghĩ ra đều tương thích với việc bảo vệ quyền riêng tư.