"Thiết kế phân mảnh Ethereum 2.0" mà mọi người đều có thể hiểu được
Lưu ý của biên tập viên: Bài viết này đến từGiá trị chuỗi carbon (ID: cc-value)Lưu ý của biên tập viên: Bài viết này đến từ
Giá trị chuỗi carbon (ID: cc-value)
Giá trị chuỗi carbon (ID: cc-value)
Khi mua đồ ăn sáng lúc 7-11 giờ, nếu chỉ có 1 thu ngân thì phải xếp hàng dài chờ tính tiền, nếu có 2 thu ngân thì nhân đôi ngay, 4 thu ngân thì có thể không có. cần xếp hàng. Đây là logic cơ bản của sharding, giúp phân phối công việc của một người cho nhiều người để nâng cao hiệu quả.
Từ quan điểm của sổ cái phân tán của Ethereum: trước khi sharding, chỉ có sổ cái của chuỗi chính, có thể xử lý khoảng 12 đến 45 giao dịch mỗi giây, khi khối lượng giao dịch lớn hơn dữ liệu này, nó cần phải xếp hàng lên, tức là mạng sẽ tắc nghẽn; Sharding là biến một sổ cái thành 64 sổ cái và để chúng xử lý các giao dịch cùng một lúc, tương đương với việc mở 64 máy tính tiền lúc 7-11 giờ để thu tiền mặt.
Logic của sharding rất đơn giản, nhưng tại sao nó lại khó thực hiện đến vậy? Bởi vì việc chia một sổ cái thành 64 sổ cái sẽ gặp phải nhiều vấn đề mới, điều mà công nghệ sharding cần làm là giải quyết chúng. Bài viết này sẽ bắt đầu từ những câu hỏi này để tìm hiểu xem sharding của Ethereum 2.0 là gì.
tiêu đề phụ
Làm thế nào để phân mảnh
1. Chỉ định giao dịch cho các phân đoạn
Một phân đoạn chứa các giao dịch và trình xác thực đóng gói các giao dịch thành các khối. Bước đầu tiên để hoàn thành một phân đoạn là xác định cách chỉ định các giao dịch và trình xác thực cho một phân đoạn. Trước tiên hãy xem xét các giao dịch phân bổ.
Chúng ta hãy dùng câu chuyện về ba ngôi làng để hiểu: có một làng đánh cá, một làng thợ săn và một làng nông dân, trong và giữa các làng thường có giao dịch, nhưng không có tiền tệ, và mọi người đều có tài khoản. Trước đây 1 sổ kế toán của 3 thôn hơi chậm, nay đổi thành 3 sổ kế toán, vậy sổ kế toán nào để kế toán những tài khoản nào?
Một phương pháp là đặt ba sổ cái ở đó, và sau khi một giao dịch đến, nó sẽ được ghi vào sổ cái nào nếu không có hàng đợi trước nó; nhưng điều này sẽ dẫn đến một vấn đề là mỗi sổ cái phải có thông tin tài khoản của chủ sở hữu, nếu không Tôi sẽ đến gặp bạn để xếp hàng và bạn không có tài khoản của tôi.
Do đó, một trong những vấn đề chính của phương pháp sharding này là nó không thể giảm lượng dữ liệu được lưu trữ trên một sổ cái và yêu cầu lưu trữ này là ngưỡng cao đối với các nút muốn tham gia vào sổ sách kế toán; phương pháp này cũng cần phải giải quyết vấn đề chi tiêu gấp đôi, bởi vì một người có thể chi tiêu cùng một số tiền vào các phần khác nhau cùng một lúc.
Một phương pháp khác là làng chài có một sổ cái, làng Orion có một sổ cái, làng nông dân có một sổ cái, sổ cái chỉ chứa thông tin tài khoản của làng của họ và chỉ ghi lại các giao dịch trong làng của họ. Bằng cách này, ba sổ cái có thể được lưu giữ cùng một lúc, với hiệu quả ghi sổ cao và yêu cầu lưu trữ ít hơn. Đây chính xác là phương pháp sharding được Ethereum áp dụng: sharding trạng thái, mỗi shard lưu trữ và chỉ lưu trữ trạng thái tài khoản thuộc về shard của chính nó. Về mặt triển khai, người dùng Ethereum chọn shard nào sẽ tham gia, thay vì sharding theo làng tự nhiên.
Vấn đề lớn nhất với sharding của nhà nước là, nếu người dân ở làng chài muốn giao dịch với người dân ở làng Orion thì sao? Không có tài khoản nào của dân làng Orion trong sổ cái của làng chài, và không có tài khoản nào của ngư dân trong sổ cái của làng Orion. Trên thực tế, đây là thử nghiệm lớn nhất đối với công nghệ sharding, giao tiếp giữa các phân đoạn. Khi vấn đề này được giải quyết hoàn toàn, Ethereum 2.0 có thể được sử dụng. Bài viết này thảo luận về một số giải pháp cho vấn đề này trong Phần II.
2. Chỉ định trình xác thực cho các phân đoạn
Sau khi sắp xếp các giao dịch vào các phân đoạn khác nhau, vấn đề tiếp theo cần giải quyết là làm thế nào để chỉ định người giữ sổ sách cho một phân đoạn, tức là chỉ định người xác minh.
Có 64 phân đoạn trong Ethereum và mỗi phân đoạn có 128 người xác minh. ? Giải pháp của Ethereum là chọn ngẫu nhiên một trình xác thực cho một phân đoạn từ tất cả các trình xác thực và thay đổi trình xác thực sau mỗi 6,4 phút (độ dài của một kỷ nguyên). Theo cách này, kẻ tấn công có ít hơn một phần nghìn tỷ cơ hội kiểm soát 2/3 số người trong một phân đoạn (xem Tham khảo 1 để biết lý do).
Một trong những nhiệm vụ chính của chuỗi đèn hiệu là gán trình xác minh cho chuỗi phân đoạn và điều quan trọng nhất trong công việc này là nhận ra tính ngẫu nhiên. Đầu tiên là tầm quan trọng của tính ngẫu nhiên, nếu không thể chỉ định ngẫu nhiên người xác minh thì không thể đảm bảo tính bảo mật của sổ cái, thứ hai là độ khó của tính ngẫu nhiên, cực kỳ khó để đạt được tính ngẫu nhiên trên blockchain, có thể coi như vậy cho đến nay Không có thuật toán ngẫu nhiên đã được chứng minh nào thực sự có thể được gọi là triển khai kỹ thuật.
Giải pháp của Ethereum là sử dụng RANDAO+VDF để cung cấp các số ngẫu nhiên nhằm đạt được tính ngẫu nhiên. Có thể hiểu đơn giản bằng cách chia RANDAO thành RAN (ngẫu nhiên) và DAO, có nghĩa là mỗi người trong nhóm đề xuất một số ngẫu nhiên một cách độc lập, sau đó kết hợp các số ngẫu nhiên của tất cả mọi người để tạo ra số ngẫu nhiên cuối cùng được sử dụng. Bởi vì rất khó để ai biết được những con số do người khác cung cấp, nên cũng rất khó để dự đoán những con số cuối cùng sẽ được kết hợp.
Tuy nhiên, có một lỗ hổng trong mô hình RANDAO, đó là người cung cấp số cuối cùng có cơ hội gian lận: anh ta biết tổng các số ngẫu nhiên do tất cả những người trước đó cung cấp và có thể điều chỉnh số do chính mình cung cấp để làm cho kết quả cuối cùng có lợi cho mình.
Để giải quyết vấn đề này, Ethereum đã giới thiệu VDF (Verifiable Delay Function), chức năng của nó rất đơn giản, đó là ngăn người cuối cùng cung cấp số ngẫu nhiên tính tổng các số ngẫu nhiên của tất cả những người trước đó trước khi tự mình cung cấp số. vì vậy Không có cách nào để thao tác các số ngẫu nhiên. (Để có phần giới thiệu chi tiết về RANDAO+VDF, xem Tài liệu tham khảo 2)
3. Các mảnh vỡ được lưu trữ bởi người chuyển tiếp
Tôi không biết bạn có để ý rằng người xác minh sổ cái luân phiên sẽ mang đến một vấn đề mới: người xác minh sẽ được chỉ định cho làng chài để giữ tài khoản trong một thời gian và sẽ được chỉ định cho Làng Orion trong một thời gian. Nếu không có đầy đủ thông tin tài khoản trong tay thì làm sao để giữ tài khoản? Nếu anh ta có tất cả thông tin tài khoản, anh ta sẽ lại nắm giữ một sổ cái đầy đủ mà không bị phân mảnh trạng thái.
Để giải quyết vấn đề này, Ethereum đã đề xuất một thiết kế mới quan trọng: ứng dụng khách không trạng thái. Hiểu một cách đơn giản là sổ cái của làng chài được đặt ở làng chài, sổ cái của làng Orion được đặt ở làng Orion, người xác minh không giữ sổ cái mà chỉ chịu trách nhiệm điều hành giữa các làng khác nhau để Giữ tài khoản.
Vậy ai sẽ giữ sổ cái của các làng khác nhau? Ethereum đã giới thiệu vai trò của người chuyển tiếp (nhà cung cấp trạng thái), người chịu trách nhiệm lưu trữ trạng thái tài khoản của các phân đoạn khác nhau và chỉ có thể phục vụ một phân đoạn nhất định. Công việc của những người tiếp sức thì dễ hiểu, nhưng trả tiền cho dịch vụ của họ như thế nào, làm sao đảm bảo tính trung thực của họ… Việc thiết kế những cơ chế liên quan này là một bài toán mới cần giải, đồng thời cũng là bài toán quản trị cộng đồng. thành viên nên tham gia thảo luận.
Nhưng chúng tôi không thể yêu cầu mỗi người dùng lưu trữ tất cả các tài khoản cũ để có thể chứng minh giao dịch sau khi giao dịch được bắt đầu. Lúc này, cần có một "rơle" để lưu trữ tất cả trạng thái tài khoản của phân đoạn. Miễn là người dùng đưa ra yêu cầu, nó sẽ Nó có thể giúp người dùng cung cấp dữ liệu nhân chứng của các giao dịch cho người xác minh.
Vitalik Buterin đã xuất bản một bài báo vào ngày 11 tháng 3 đề xuất thay thế gốc trạng thái bằng cam kết đa thức. Công nghệ này được sử dụng tại đây. Nó sử dụng phương pháp bằng chứng không kiến thức để cung cấp bằng chứng cho giao dịch, có thể hiểu là cung cấp kết quả tính toán của dữ liệu. Thay vì trực tiếp cung cấp tất cả dữ liệu liên quan cho người xác minh để xác minh, phương pháp này có thể giảm đáng kể kích thước của dữ liệu nhân chứng và giảm các chi phí khác nhau một cách hiệu quả. (Để biết phần giới thiệu chi tiết về phương pháp mới của Vitalik, hãy xem Tài liệu tham khảo 3 và để biết phần giới thiệu chi tiết về ứng dụng khách không trạng thái, hãy xem Tài liệu tham khảo 4)
Tại thời điểm này, công việc chia sổ cái thành nhiều sổ cái, tức là chia thành các phần, đã hoàn thành.
tiêu đề phụ
Giao dịch trên các phân đoạn
Nếu người làng chài chỉ giao dịch với người làng chài, và người làng Orion chỉ giao dịch với người làng Orion, thì mỗi làng có thể giữ tài khoản của riêng mình, điều này không cần bất kỳ công nghệ mới nào . Nhưng nếu những người ở làng chài muốn giao dịch với những người ở làng Orion thì làm thế nào các sổ cái khác nhau có thể giao tiếp với nhau? Đây là vấn đề hóc búa nhất mà việc bảo vệ trạng thái phải đối mặt.
Có hai cách để giải quyết vấn đề này, một là đồng bộ (ghép chặt) và cách còn lại là không đồng bộ (gắn lỏng).
Giả sử có một người tên A ở làng chài và một người tên B ở làng Orion, A muốn đưa cho B 100 nhân dân tệ. Đồng bộ hóa có nghĩa là: khi A bắt đầu chuyển tiền, nhân viên kế toán ở làng chài và làng Orion biết giao dịch và tiến trình của giao dịch. Nhân viên kế toán trừ 100 từ A trên sổ cái và nhân viên kế toán của Làng Orion cộng 100 vào B trên sổ cái. Sau khi giao dịch hoàn tất, hai làng tạo ra các khối mới đồng thời.
Không đồng bộ có nghĩa là: khi A bắt đầu chuyển tiền, sổ tài khoản của làng chài giảm A đi 100 và một khối mới được tạo; nhân viên kế toán của Làng Orion nhận được thông báo này theo một cách nào đó sau đó và sau khi xác nhận rằng tiền của A thực sự đã được chuyển giảm, anh ta sẽ thêm 100 vào B trên sổ tài khoản của chính mình và giao dịch đã hoàn tất, nhưng hai làng tạo ra các khối mới không đồng bộ.
Phương thức đồng bộ hóa trông có vẻ thân thiện, giao diện của quá trình thực hiện giao dịch cũng giống như không phân mảnh, nhưng nó ẩn chứa một vấn đề lớn, đó là rất khó đối phó với "sự thay đổi trạng thái liên tục". Nó có nghĩa là gì?
Nếu A chỉ chuyển 100 nhân dân tệ cho B, sau khi nghe giao dịch, làng chài và làng Orion có thể dễ dàng xác nhận rằng mọi người đều giữ tài khoản theo cách này, sổ tài khoản của làng chài sẽ giảm 100 cho A và làng Orion sẽ cộng 100 vào B. Ghi sổ kế toán đầy đủ. Tuy nhiên, nếu A chuyển 100 cho B, sau đó chuyển cho B 50, trạng thái thay đổi liên tục xảy ra, nhưng A chỉ có tổng cộng 120. Lúc này, hai làng khó xác nhận bên kia giữ tài khoản như thế nào:
Nếu mỗi người xác nhận tự mình giao tiếp với người xác nhận của người kia, thì chi phí liên lạc sẽ tăng mạnh và sẽ cực kỳ khó đạt được một kết quả nhất định; nếu giao tiếp thông qua trưởng thôn của cả hai bên, mỗi làng cần tiến hành một vòng đồng thuận trước, sau đó Trưởng làng cho bên kia biết kết quả xác định, ngoài việc tăng chi phí, điều này cũng khó đạt được vì bản thân cơ chế đồng thuận của Ethereum không thể đạt được kết quả xác định (cuối cùng).
Phương pháp không đồng bộ sẽ không gặp rắc rối với các thay đổi trạng thái liên tục, bởi vì cách tiếp cận của nó là "chờ". Khi trạng thái của bạn được xác nhận, tôi sẽ tiến hành bước tiếp theo; Sau khi trừ 100 hoặc 50, hãy quyết định thêm 100 hoặc 50 vào B.
Vấn đề với cách tiếp cận không đồng bộ là lỗi nguyên tử. Giao dịch phải là nguyên tử, được thực hiện hoặc không được thực hiện, nhưng theo cách không đồng bộ, có thể một phần của giao dịch được xác nhận nhưng phần khác bị loại bỏ.
Ví dụ: khối trong đó làng chài trừ 100 từ A cuối cùng đã được xác nhận trên chuỗi chính của làng chài, nhưng khối trong đó Làng Orion cộng 100 vào B cuối cùng đã bị bỏ rơi trên chuỗi phụ của Làng Orion. Lỗi nguyên tử là một vấn đề, nhưng nó có thể được giải quyết bằng thiết kế. Để biết phần giới thiệu chi tiết về phần này, hãy xem phần tham khảo 5 ở cuối bài viết.
Ethereum đã thảo luận về một số mô hình kiến trúc không đồng bộ. các khối và liên kết chéo với các khối chuỗi đèn hiệu. Phương thức kết nối như trong hình bên dưới. Bằng cách này, bất kỳ đoạn nào cũng có thể biết thông tin của tất cả các đoạn khác thông qua chuỗi đèn hiệu khi đóng gói giao dịch mới của chính nó. Một vị trí không đồng bộ giữa các phân đoạn khác nhau.
Phương pháp này làm giảm độ trễ của các giao dịch giữa các phân đoạn, nhưng tăng các yêu cầu đối với chuỗi đèn hiệu, cần lưu trữ dữ liệu bằng chứng cho tất cả các phân đoạn; phương pháp này cũng làm tăng số lượng liên kết được liên kết chéo (được thiết kế ban đầu là Mỗi kỷ nguyên, nghĩa là , 6,4 phút, 32 khối liên kết chéo một lần), điều này chắc chắn sẽ làm tăng các chi phí liên quan khác nhau và do đó, số lượng phân đoạn trong Ethereum đã được thay đổi từ 1024 thành 64, từ một hướng thiết kế khác Giảm tổng số liên kết. (Xem Tài liệu tham khảo 6 để biết phần giới thiệu chi tiết về kiến trúc)
Đánh giá từ một số sơ đồ thiết kế sharding hiện tại, mô hình đồng bộ có xu hướng giao tiếp giữa các phân đoạn và chính các phân đoạn, trong khi mô hình không đồng bộ có xu hướng giao tiếp giữa các phân đoạn và phân đoạn thông qua bên thứ ba; thứ hai phải đối mặt với một vấn đề cân bằng của nhiều chi phí. Việc thiết kế và triển khai các giao dịch giữa các phân đoạn vẫn đang được tiến hành và không chắc chắn Ethereum 2.0 cuối cùng sẽ áp dụng kiến trúc nào.
tiêu đề phụ
Hợp đồng thông minh trên các phân đoạn
Sau khi giới thiệu các giao dịch sharding và cross-shard, ông chủ lớn cuối cùng trên con đường phát triển Ethereum 2.0 xuất hiện, đó là hợp đồng thông minh cross-shard. Sự khác biệt giữa giao dịch giữa các phân đoạn và hợp đồng thông minh giữa các phân đoạn là giao dịch chỉ có các biến toàn cầu, trong khi hợp đồng thông minh có các biến cục bộ. Biến cục bộ gây ra rắc rối gì?
Sau khi sharding, Ethereum có 64 sổ cái theo quan điểm vật lý, nhưng chỉ có một sổ cái theo quan điểm trừu tượng: sổ cái có thể được hình dung như một cái cây lớn, mỗi lá của cây lưu trữ dữ liệu trạng thái tài khoản, 64 Sổ cái là 64 cây, sau đó rễ của những cây này được đưa vào chuỗi đèn hiệu để tạo thành một cây lớn mới và 64 sổ cái được kết hợp thành một sổ cái (đây chỉ là một phép ẩn dụ gần đúng).
Trong các giao dịch giữa các phân đoạn, khi một phân đoạn cần biết trạng thái tài khoản của một phân đoạn khác, nó luôn có thể theo dõi cây để tìm lá lưu trữ trạng thái, sau đó thay đổi trạng thái tài khoản phân đoạn của chính nó và hoàn tất giao dịch. Có thể coi rằng thông qua cây này, các mảnh khác nhau hoàn thành việc truyền đạt thông tin.
Nhưng đối với các hợp đồng thông minh trên các phân đoạn, vấn đề phát sinh. Dữ liệu được lưu trữ trên các lá của cây này đều là các biến toàn cục và không có biến cục bộ. Nếu một hợp đồng thông minh trong một phân đoạn gọi một hợp đồng thông minh trong một phân đoạn khác, điều gì sẽ xảy ra với hai Truyền thông tin cho các biến cục bộ? Cây không thể phục vụ họ.
Hiện tại, không có sơ đồ thiết kế phân đoạn chéo hợp đồng thông minh có hệ thống, nhưng có hai đề xuất, một là đưa các hợp đồng thông minh có liên quan vào cùng một phân đoạn để thực thi, nghĩa là loại bỏ phân đoạn chéo hợp đồng thông minh. đề xuất sử dụng công nghệ SIMD (Luồng hướng dẫn đơn Nhiều luồng dữ liệu), để bản thân hợp đồng thông minh có thể được thực thi song song.
Người giới thiệu:
1.《 Minimum Committee Size Explained》Ethereum 2.0 sẽ giới thiệu các hợp đồng thông minh trong Giai đoạn 2, điều đó có nghĩa là việc chia sẻ chéo các hợp đồng thông minh sẽ không được thực hiện cho đến Giai đoạn 2 và chỉ sau bước này mới có thể thực sự tuyên bố rằng Ethereum đã bước vào kỷ nguyên 2.0.
3.《Using polynomial commitments to replace state roots》; Tác giả, Chih-Cheng Liang;
4."Ethereum 2.0: Tính ngẫu nhiên"; Tác giả, Bruno Škvorc; Dịch giả, Jhonny, A Jian;
5.; Tác giả, Vitalik Buterin;"Mạng chuyển tiếp ETH2.0 và cơ chế phí"
6.《Eth2 shard chain simplification proposal》; Tác giả, John Adler; Dịch giả, IAN LIU, A Jian;
7."Khái niệm và thách thức của sự phân mảnh chuỗi khối"; Tác giả, Alexander Skidanov; Dịch giả, Jhonny, Echo, A Jian;
8.《Merge blocks and synchronous cross-shard state execution》; Tác giả, Vitalik Buterin;
