Lưu ý của biên tập viên: Bài viết này đến từPhòng thí nghiệm Ambi (ID: secbitlabs), được in lại bởi Odaily với sự cho phép.

Lưu ý của biên tập viên: Bài viết này đến từ

Phòng thí nghiệm Ambi (ID: secbitlabs)

, được in lại bởi Odaily với sự cho phép.

Ethereum cũng đã thử nhiều phương pháp khác nhau để cải thiện hiệu suất, trước khi ra mắt phiên bản 2.0, nó đã "thử" mã hóa. Ethereum 2.0 sẽ là một chuỗi công khai dựa trên "hệ thống phân tán + mật mã". Mật mã này không đề cập đến phần được sử dụng cho chữ ký và quyền riêng tư, mà đề cập đến thành phần cốt lõi của hệ thống hiệu suất cao, phần đó.

Từ quan điểm này, có lẽ chúng ta có thể nói rằng không phải những người khác lật đổ Ethereum, mà là chính nó. Nó nhảy ra khỏi ý tưởng duy nhất về thiết kế hệ thống phân tán và bắt tay vào con đường thiết kế kết hợp hệ thống phân tán + mật mã.

Bài viết này sẽ cố gắng giới thiệu cách thiết kế hệ thống phân tán được kết hợp với thiết kế mật mã trong Ethereum 2.0 để đạt được bước đột phá trong hiệu suất của chuỗi công khai.

tiêu đề phụ

State sharding: từ sổ cái đơn đến nhiều sổ cái

Chuỗi khối là một sổ cái phân tán và các nút khối là những người khai thác giữ tài khoản và họ chịu trách nhiệm ghi các giao dịch vào sổ cái. Ngoài việc cạnh tranh quyền ghi sổ, công việc quan trọng nhất của các nhà sản xuất khối, hoặc công việc của chính họ, là kiểm tra xem các giao dịch mà họ đóng gói có hợp pháp hay không. Không khó để hoàn thành công việc này, bởi vì nút tạo khối nắm giữ sổ cái trong tay và nó chỉ cần kiểm tra xem người gửi giao dịch có tiền hay không.

Đối với chuỗi công khai không bị phân mảnh, tất cả các nút đều giữ cùng một sổ cái; và để tránh xung đột sổ sách kế toán, chỉ một nút tạo khối được phép giữ sổ sách tại một thời điểm. Ethereum đề xuất phân đoạn trạng thái, thực tế là chia một sổ cái thành nhiều sổ cái. Bằng cách này, một số nút giữ tài khoản ở sổ cái số 1 và một số nút giữ tài khoản ở sổ cái số 2... (tương đương với 7-11 từ tiền mặt đăng ký Nền tảng được tăng lên thành nhiều máy tính tiền) và nhiều nút giữ tài khoản cùng một lúc và hiệu suất của toàn bộ chuỗi công khai sẽ được cải thiện về chất lượng.

Nhưng nếu chúng ta sửa mối quan hệ giữa các nút tạo khối và sổ cái/phân đoạn chẳng hạn, xác định được rằng bốn nút a, b, c và d phụ trách sổ cái số 1, thì kẻ xấu chỉ cần mua một số a, b, c và d. Nó có thể phá hủy sổ cái và trong khi hiệu suất của chuỗi công khai được cải thiện, tính bảo mật sẽ giảm theo tỷ lệ tương tự.

Giải pháp mà Ethereum đưa ra là nút tạo khối không cần bất kỳ sổ cái nào, hay nói cách khác, nút tạo khối không cần sổ cái để lưu giữ tài khoản.

Điều này sẽ mang lại hai lợi ích chính: Thứ nhất, bất kể nút được gán cho phân đoạn nào, nó có thể bắt đầu ghi sổ kế toán (sản xuất khối) ngay lập tức và hầu như không mất thời gian để lấy và đồng bộ hóa sổ cái của phân đoạn. dễ dàng chuyển đổi giữa các phân đoạn khác nhau; thứ hai là nút tạo khối không cần lưu trữ sổ cái và không cần cấu hình phần cứng cao. Bất kỳ ai thế chấp 32ETH đều có thể trở thành trình xác nhận, điều này rất hữu ích cho việc phân cấp Ethereum PoS Và bảo mật của toàn bộ chuỗi công khai.

Nhưng một vấn đề mới xuất hiện: Nếu nhà sản xuất khối không có sổ cái, làm thế nào để biết liệu người gửi giao dịch có đủ tiền hay không? Đây là nơi mật mã phát huy tác dụng.

tiêu đề phụ

Cam kết Vector: Từ truy vấn đến bằng chứng

Nghe có vẻ khó tin khi có thể giữ tài khoản mà không cần sổ cái, nhưng ý tưởng rất đơn giản: trước đây, một nút có sổ cái và sau khi giao dịch đến, nó sẽ xem qua sổ cái để kiểm tra xem giao dịch đó có hợp pháp hay không; trong tương lai, nút không có sổ cái và người gửi giao dịch Khi gửi giao dịch, bạn cần gửi bằng chứng mật mã (để phân biệt, văn bản sau đây đề cập đến bằng chứng mật mã làm bằng chứng) và bạn có thể chứng minh rằng giao dịch của mình là hợp pháp.

Tại sao nút tạo khối có thể đánh giá liệu một giao dịch nhất định có hợp pháp hay không thông qua bằng chứng? Hai khái niệm quan trọng về mật mã có liên quan ở đây, khái niệm đầu tiên được gọi là "Bằng chứng thành viên". Nó đề cập đến quá trình chứng minh rằng một cá nhân là một phần của một nhóm. Nếu có thể chứng minh rằng một trạng thái tài khoản nhất định là một phần của toàn bộ trạng thái sổ cái, thì nút tạo khối tất nhiên có thể tin vào trạng thái tài khoản này và sử dụng điều này làm cơ sở để đánh giá tính hợp pháp của giao dịch.

Cái thứ hai được gọi là "Cam kết véc tơ", có thể nén một nhóm, bất kể nhóm đó lớn đến đâu, thành một số duy nhất, sau đó đưa ra bằng chứng về tư cách thành viên, cho thấy một cá nhân thuộc nhóm đứng sau số Nhóm. , và có thể chứng minh vị trí của cá nhân trong nhóm, đồng thời cập nhật chứng chỉ.

Hình bên dưới là một cây Merkle, các nút lá ở lớp dưới cùng lưu trữ dữ liệu ứng dụng và các nút không phải lá khác lưu trữ giá trị băm của các nút con của chúng. Nếu bạn biết giá trị của nút màu xanh lá cây và tất cả các nút màu vàng, bạn có thể thực hiện ba thao tác băm từ dưới lên trên để lấy giá trị gốc của cây Merkle, là 6c0a.

Khi đó, nếu bên xác minh có giá trị gốc cây (6c0a), bên cung cấp bằng chứng lấy giá trị của nút xanh và tất cả giá trị của các nút vàng làm bằng chứng cho bên xác minh, bên xác minh có tính toán được không? giá trị băm ba lần bằng 6c0a để đánh giá xem giá trị của nút xanh có trong cây Merkle này hay không? Câu trả lời là có. Đây là bằng chứng về tư cách thành viên của nút màu xanh lá cây đối với cây Merkle, được thực hiện như một cam kết véc tơ và đây gần như là cách thức hoạt động của các nút Bitcoin SPV (Xác minh thanh toán đơn giản).

Như thể hiện trong hình bên dưới, nút SPV không lưu trữ toàn bộ khối/sổ cái mà lưu trữ gốc của cây Merkle trong mỗi khối (các nút lá của cây Merkle lưu trữ tất cả các giao dịch trong khối), khi cần truy vấn Khi một giao dịch tồn tại, nút đầy đủ sẽ được yêu cầu cung cấp bằng chứng về giao dịch, tương tự như một gói (đường dẫn Merkle) của các giá trị nút xanh và nút vàng ở trên, sau đó nút SPV sẽ tính tổng băm của những giá trị này Liệu giá trị có bằng với giá trị gốc của cây Merkle trong tay của chính bạn hay không. Nếu chúng bằng nhau, điều đó có nghĩa là giao dịch là thành viên của cây Merkle, nghĩa là giao dịch tồn tại.

Mô tả hình ảnh

Nút SPV đánh giá liệu giao dịch có tồn tại thông qua bằng chứng thành viên hay không. Hệ thống bằng chứng bao gồm ba phần: nút có một bản tóm tắt ngắn (gốc cây); nhà cung cấp bằng chứng đưa ra bằng chứng; nút tính toán bằng chứng để xem liệu nó có phù hợp với bản tóm tắt trong trận đấu tay của riêng mình.

Tại thời điểm này, chúng tôi đã hoàn thành "kiểm tra tài khoản mà không cần sổ cái", đó là thay đổi suy nghĩ truy vấn sang tư duy chứng minh; điều tiếp theo chúng tôi muốn đạt được là "giữ tài khoản mà không cần sổ cái".

Đối với các nút tạo khối trên phân đoạn Ethereum 2.0, hệ thống bằng chứng của nó cũng bao gồm ba phần: tóm tắt, bằng chứng và xác minh, nhưng nó phải sử dụng bằng chứng do người gửi giao dịch cung cấp (không phải nút đầy đủ) để đánh giá xem liệu một nút mới hay không. giao dịch là hợp pháp (chứ không phải là liệu giao dịch cũ có tồn tại hay không) và sử dụng phán đoán này làm cơ sở để hạch toán.

tiêu đề phụ

Không quốc tịch: Từ Proof of Ledger đến Proof of Behavior

Hãy tưởng tượng một ngôi làng nhỏ chỉ có 3 giao dịch giữa dân làng mỗi ngày và trưởng làng chịu trách nhiệm giữ các tài khoản với sổ cái. Bây giờ A muốn chuyển 5 nhân dân tệ cho B. Ý tưởng truyền thống rất đơn giản: trưởng thôn kiểm tra xem có 5 nhân dân tệ trong tài khoản của A hay không, và nếu có, hãy ghi lại giao dịch mới này.

Bây giờ hãy thay đổi cách suy nghĩ: Giả sử sáng nay A muốn chuyển 5 tệ cho B, và trưởng thôn biết sáng hôm qua tài khoản của A có 10 tệ, thì nếu A chứng minh được 3 giao dịch hôm qua không liên quan gì đến mình, phải không Có nghĩa là tài khoản của anh ấy vẫn còn 10 đô la sáng nay? Theo cách này, trưởng thôn có thể ghi lại giao dịch mới này mà không cần kiểm tra sổ cái không? Câu trả lời là có.

Nếu hôm qua A có giao dịch thì sao? Rất đơn giản, lúc này A không chứng minh mình không có giao dịch, mà chứng minh hôm qua chỉ giao dịch một lần, giao dịch đó tốn 3 tệ, trưởng thôn biết anh ta còn 7 tệ nên có thể ghi lại. giao dịch mới.

Sự thay đổi tư duy này rất quan trọng, và bạn phải hiểu nó, đây là bí ẩn của điều "không quốc tịch". Không khó để nhận thấy rằng ngay cả một nút SPV không chứa sổ cái thực sự cần sử dụng sổ cái hoặc trạng thái khi truy vấn các giao dịch, nhưng nó không tự lưu trữ trạng thái mà đi đến toàn bộ nút để lấy nhưng theo ý tưởng mới này, vai trò của trạng thái có thể được thay thế hoàn toàn bằng "bằng chứng hành vi", thì chuỗi này có thể được thiết kế theo cách không trạng thái. (Lưu ý: Từ "chứng minh hành vi" không có nguồn, tác giả mô tả lại cho dễ hiểu)

Làm thế nào để đạt được tình trạng không quốc tịch? Làm thế nào để hoàn thành sổ sách kế toán với sự trợ giúp của bằng chứng về hành vi? Nó vẫn là phương pháp chứng nhận thành viên. Có thể sử dụng cây Merkle để hoàn thành bằng chứng thành viên này không? Về lý thuyết, điều đó là có thể, nhưng đối với kịch bản ứng dụng "không trạng thái", chi phí sử dụng nó quá cao. Trong bài viết này, chúng tôi giới thiệu Bằng chứng về tư cách thành viên thông qua các Cam kết của người phụ có thể tổng hợp để ghi sổ kế toán không có sổ cái.

Cam kết vectơ con tổng hợp (aSVC) là một nỗ lực nghiên cứu gần đây từ bài báo "Cam kết vectơ con tổng hợp cho tiền điện tử không trạng thái" của Alin Tomescu, Ittai Abraham, Vitalik Buterin (Ethereum), Justin Drake (Ethereum Square), Dankrad Feist (Ethereum), Dmitry Khovratovich (Ethereum). Quy trình làm việc của nó như sau:

1. Khởi tạo sharding, tức là xác định tình hình ban đầu của tài khoản khi sổ tài khoản được thiết lập. Giả sử một phân đoạn có 100 tài khoản khi được thành lập và các tài khoản này có số dư ban đầu, chúng ta cần sử dụng v(i) để biểu diễn tài khoản thứ i, là một cặp giá trị như (địa chỉ i, số dư i ); sử dụng V Đại diện cho tất cả các tài khoản, nó là một tập hợp các giá trị như (địa chỉ 1, số dư 1) (địa chỉ 2, số dư 2)...(địa chỉ 100, số dư 100).

Đồng thời, cần tạo ra hai giá trị, giá trị đầu tiên được gọi là c, là cam kết với V, đại diện cho tất cả các tài khoản và số dư trong tài khoản của shard tại thời điểm này. Các nút tạo khối nắm giữ c trong tay (có thể so sánh nó với gốc của cây Merkle cho dễ hiểu), đây là bản tóm tắt để xác minh trong tương lai.

Cái thứ hai được gọi là π(i), là bằng chứng cho thấy v(i) là thành viên của V, đại diện cho tài khoản thứ i và số dư của tài khoản nằm trong sổ cái V. Mỗi tài khoản nắm giữ và chỉ nắm giữ π(i) của riêng mình, đây là bằng chứng được gửi tới nút khối khi gửi giao dịch trong tương lai.

Trong giai đoạn khởi tạo, việc tạo ra các cam kết và bằng chứng yêu cầu một "trạng thái" ban đầu.

2. Giao dịch đầu tiên. Tài khoản i bắt đầu giao dịch đầu tiên của toàn bộ phân đoạn. Lúc này, nó cần gửi π(i) và giao dịch cho nút khối và nút khối tính toán π(i) để xem kết quả có phù hợp với c trong tay của chính nó. Nếu chúng trùng khớp, bạn có thể tin rằng tài khoản của người gửi có bao nhiêu số dư và sử dụng thông tin này để đánh giá liệu giao dịch mà người gửi đã gửi có hợp pháp hay không.

3. Tiếp theo là điểm mấu chốt: cập nhật c và π(i).

c (cam kết với toàn bộ sổ cái) không còn được tạo theo trạng thái, nó được tạo bằng cách sử dụng c trước giao dịch đầu tiên và thay đổi số dư do giao dịch đầu tiên gây ra; π(i) (bằng chứng về chính tài khoản) Không phải là được tạo theo trạng thái, nó được tạo bằng π(i) trước khi giao dịch đầu tiên xảy ra và thay đổi tài khoản theo giao dịch đầu tiên.

Sau khi hoàn thành cập nhật c và π(i), nút tạo khối có một cam kết mới (c mới) có thể hứa hẹn số dư mới của tất cả người dùng và tài khoản cũng có bằng chứng mới (π(i) mới có thể chứng minh số dư mới của nó )).

Tương tự, mỗi giao dịch sẽ thay đổi c một lần và thay đổi tất cả π(i) một lần, nhưng sự thay đổi này không còn phụ thuộc vào dữ liệu trạng thái, nó phụ thuộc vào c và π(i) cũ, cũng như giao dịch trước đó; khi Khi một giao dịch mới cần được xác minh, nút tạo khối luôn có c mới nhất trong tay. Nó có thể đánh giá liệu một giao dịch có hợp pháp hay không và liệu nó có thể được đóng gói thành một khối thông qua c và π(i) được cung cấp bởi tài khoản.

Vì vậy, tại thời điểm này, "tài khoản có thể được lưu giữ mà không cần sổ cái" cuối cùng đã được nhận ra. Cho dù đối với nhà sản xuất khối hay tài khoản, những gì họ nắm giữ trong tay là một số loại bằng chứng mật mã, không phải trạng thái của sổ cái. Cũng cần đề cập rằng trạng thái không trạng thái và sharding dường như là một sự kết hợp hoàn hảo, nhưng trạng thái không trạng thái không phải là một thiết kế dành cho sharding, nó là một thiết kế dành cho các chuỗi công khai.

Mục tiêu thiết kế của aSVC là trở thành một bằng chứng hiệu quả về tư cách thành viên, giảm chi phí giao tiếp và chi phí tính toán trong quy trình trên, để sơ đồ này có thể được sử dụng để triển khai chuỗi khối không trạng thái. Theo quan điểm của bài báo, sử dụng sơ đồ aSVC, kích thước của c và π(i) chỉ vài chục byte, thời gian cập nhật của π(i) là O(1) và thời gian xác minh cũng là O( 1). Nó hỗ trợ tổng hợp nhiều bằng chứng thành một bằng chứng O(1). Việc triển khai chi phí thấp này chính xác là những gì aSVC hướng tới. Tuy nhiên, giống như cuộc thảo luận của Vitalik trong Diễn đàn nhà nghiên cứu Ethereum, aSVC vẫn cần tối ưu hóa hơn nữa.

Cuối bài viết là một bản tóm tắt ngắn gọn về toàn văn: thiết kế bảo vệ trạng thái của hệ thống phân tán được kết hợp với thiết kế bằng chứng thành viên của mật mã để đạt được bước đột phá trong hiệu suất của Ethereum 2.0.

1. Để đảm bảo an toàn, trạng thái sharding của Ethereum 2.0 cần chỉ định ngẫu nhiên các nút tạo khối.

2. Nếu các nút tạo khối cần sổ cái, thì việc đồng bộ hóa sổ cái sẽ trở thành nút cổ chai hiệu suất mới và việc lưu trữ sổ cái cũng sẽ ảnh hưởng đến việc phân cấp PoS.

4. Thay đổi thứ nhất về tư duy: thay đổi cách tra cứu sổ cái sang cách chứng minh sổ cái. Điều này cần phải được thực hiện với sự trợ giúp của mật mã.

5. Thay đổi tư duy thứ hai: thay đổi cách chứng minh trạng thái của sổ cái sang cách chứng minh hành vi giao dịch, và thực hiện phi trạng thái và ghi sổ mà không cần sổ cái. Điều này cần phải được thực hiện với sự trợ giúp của mật mã.

6. Công cụ mật mã có nhiều, khi đã có mục tiêu cần lựa chọn, kết hợp các công cụ thích hợp để tạo thành giải pháp theo yêu cầu ứng dụng, tối ưu hóa giải pháp.

tiêu đề phụ

Easter egg: hứa hẹn subvector tổng hợp

Trong bài viết chúng tôi mô tả hoạt động của aSVC bằng ngôn ngữ tự nhiên, nếu quan tâm bạn có thể hiểu rõ hơn qua định nghĩa API của aSVC. Như thể hiện trong hình bên dưới: hộp màu đỏ đầu tiên là tạo cam kết c trong quá trình khởi tạo, hộp màu đỏ thứ hai là cập nhật c theo giao dịch; hộp màu xanh lá cây đầu tiên là tạo bằng chứng π(i) trong quá trình khởi tạo và hộp màu xanh lá cây thứ hai là Cập nhật giao dịch π(i); hộp màu xanh lam là nút khối sử dụng c và π(i) để xác minh.

Trong quy trình trên, công việc cốt lõi là thay đổi c cũ thành c mới và thay đổi π(i) cũ thành π(i) mới theo những thay đổi do giao dịch gây ra. Bản cập nhật không chỉ phải có khả năng hoàn thành mà chi phí cho bản cập nhật này cũng phải chấp nhận được, đây là vấn đề chính mà aSVC cần giải quyết. Hãy lấy bản cập nhật của c làm ví dụ để giới thiệu cách aSVC thực hiện.

Như đã đề cập ở trên, những gì c hứa hẹn là V, và từ c đến c mới thực chất là từ hứa hẹn với V sang hứa hẹn với V mới. Đối với V, nó bao gồm một loạt các điểm, (địa chỉ 1, số dư 1) là một điểm, (địa chỉ 2, số dư 2) là một điểm khác... (địa chỉ 100, số dư 100) là điểm thứ 100.

Với sự trợ giúp của phép nội suy Lagrange, chuỗi điểm này có thể được biến thành một đa thức (đường cong được biểu thị bởi đa thức đi qua tất cả các điểm này), điều đó có nghĩa là cam kết đối với một chuỗi điểm có thể được chuyển thành cam kết đối với đa thức ; Từ c đến c mới tương đương với việc đi từ một đa thức này sang một đa thức khác.https://eprint.iacr.org/2020/527.pdf。