ETH 2.0 là gì?
ETH2.0 là sự thay thế cho Ethereum. Trong vài năm tới, các nhà thiết kế ETH2.0 có ý định gộp hoàn toàn hệ thống đồng thuận và trạng thái của Ethereum lại với nhau. Với phạm vi rộng như vậy, chúng ta không thể nói chính xác những gì ETH2.0 sẽ hoặc sẽ không bao gồm. Chúng tôi có một vài thông số kỹ thuật và khá nhiều đội ngũ đang lên kế hoạch triển khai sớm. Tại thời điểm này, các nhà thiết kế ETH2.0 dự kiến sẽ bao gồm sharding, Casper, tiền thuê kho lưu trữ và máy ảo eWASM. Thử nghiệm client ban đầu đang được tiến hành và một testnet ETH2.0 bản light dự kiến sẽ ra mắt trong vòng ba tháng (Q1 2019). Lúc đầu, ETH2.0 sẽ lấy Ether của nó (chứ không phải là chứng khoán của nó) từ chuỗi Ethereum chính, nhưng cuối cùng các nhà thiết kế đã có kế hoạch đảo ngược mối quan hệ bằng cách biến ETH2.0 thành chuỗi chính và Ethereum 1.X thành chuỗi shard dưới sự quản lý của nó.
Vậy điều này có ý nghĩa gì với các kỹ sư?
Nếu bạn là nhà phát triển Solidity hoặc Dapp đang hy vọng triển khai các hợp đồng thông minh ETH2.0, thì hãy mong đợi nhiều sự thay đổi đang sắp diễn ra. ETH2.0 là sự thay thế hoàn toàn cho Ethereum và sẽ thay đổi nhiều giả định mà chúng ta đưa ra khi viết hợp đồng thông minh. Việc triển khai theo ‘giai đoạn nhiều năm’ theo kế hoạch của nó mang nhiều điểm tương đồng với chu kỳ phát hành sản phẩm hơn là chu kỳ nâng cấp. Các công cụ và hợp đồng mà chúng tôi đã viết cho ETH1.X có thể sẽ cần phải được thiết kế lại và viết lại hoàn toàn cho ETH2.0. May mắn thay, chúng tôi có một vài năm để chuẩn bị hệ sinh thái. Để tiếp tục, tôi muốn thảo luận về lộ trình hiện tại và đề cập đến một số phân nhánh kỹ thuật.
Triển khai theo giai đoạn (Phased Rollout)
Hiện tại, lộ trình sharding (tăng gấp đôi so với lộ trình ETH2.0) có 7 giai đoạn (phase) được liệt kê. Chỉ Giai đoạn 0 có thông số kỹ thuật xác thực, nhận được cập nhật thường xuyên. Đặc điểm kỹ thuật của Giai đoạn 1 kém chính xác hơn nhiều và dường như chưa được phát triển tích cực. Sau Giai đoạn 1, lộ trình trở thành một danh sách các mục tiêu, thay vì tài liệu kỹ thuật. Ví dụ, trong Giai đoạn 2, lộ trình liên kết đến ethresear.ch nhiều hơn ba lần so với github. Bởi vì bất cứ điều gì nằm ngoài sẽ trông giống như đầu cơ thay vì kỹ thuật, cuộc thảo luận cụ thể của chúng ta được giới hạn ở các Giai đoạn 0, 1 và 2, và chúng tôi đã bao gồm một số phác thảo sơ bộ về các hướng đi khả thi cho các giai đoạn sau.
Giai đoạn 0 – Beacon Chain (chuỗi Beacon)
Giai đoạn 0 giới thiệu “beacon chain.” Các nhà thiết kế của ETH2.0 dự định beacon chain sẽ trở thành trung tâm của hệ sinh thái ETH2.0, trở thành nguồn gốc bảo mật và xác thực cho tất cả các phân đoạn (shard) khác. Sau khi được triển khai, beacon chain sẽ chạy bằng chứng cổ phần bằng cách sử dụng Casper the Friendly Finality Gadget (“Casper FFG”). Việc lặp lại sớm này của beacon chain được thiết kế đơn giản nhất có thể, đó là lý do tại sao Giai đoạn 0 sẽ không hỗ trợ hợp đồng thông minh, tài khoản, chuyển nhượng tài sản và sẽ không bao gồm bất kỳ phân đoạn nào. Ether trên beacon chain sẽ không thể chuyển nhượng trên chuỗi, điều đó có nghĩa là người dùng sẽ không thể gửi tiền vào các sàn giao dịch.
BETH – “Ether mới”
Beacon ETH (BETH) là một loại tài sản mới chỉ được sử dụng bởi các nhà sản xuất (‘người xác nhận hợp lệ’) trên beacon chain. Nó được tạo thông qua hai phương thức: 1) như một phần thưởng để xác nhận beacon chain (và các shard, sau Giai đoạn 1) và 2) BETH có thể được mua vơia 1 ETH bởi bất kỳ người dùng ETH1.X nào thông qua hợp đồng ETH1.X. Hợp đồng đề cập đến điều này như một ‘khoản ký gửi’. Các kỹ sư có thể nhận thấy rằng hợp đồng không có chức năng rút tiền. Điều này là do không có cách nào để rút BETH khỏi beacon chain trong giai đoạn 0. Điều đó có nghĩa là, một khi đã ký gửi trong hợp đồng đăng ký xác thực ETH1.X, Ether ETH1.X bị đốt cháy một cách hiệu quả. Người xác nhận beacon chain xem hợp đồng này và đưa thông tin tiền gửi cho beacon chain, nơi sẽ phát hành BETH mới cho người gửi tiền. Do đó, chúng tôi hy vọng BETH mới sẽ được phát hành trên beacon chain ngay sau khi ETH được gửi đến hợp đồng đăng ký xác nhận. Kiểm duyệt tạm thời một khoản tiền gửi là có thể, nhưng kiểm duyệt vĩnh viễn không có khả năng xảy ra theo các quy tắc của Casper.
Việc chuyển Ether trên beacon chain sẽ không thực hiện được cho đến Giai đoạn 2 và tôi không tin rằng sẽ có bất kỳ cách nào để chuyển BETH trở lại ETH1.X cho đến khi 1.X hoàn toàn được xếp vào hệ sinh thái shard. Giả sử Giai đoạn 0 không đầy đủ và Giai đoạn 1 không có thông số kỹ thuật đáng tin cậy nào, có vẻ hợp lý khi cho rằng BETH sẽ tồn tại như một tài sản độc lập và không thể chuyển nhượng trong ít nhất hai năm. Khi Giai đoạn 2 hoàn tất, BETH sẽ được chuyển đến và đi từ các phân đoạn; tuy nhiên, ETH sẽ không như vậy. Điều này không có khả năng gây ra những khó khăn kinh tế đáng kể. Trong quá khứ, các token trong giai đoạn trước khi ra mắt và có tính năng thấp như BETH đã được giao dịch trên các sàn giao dịch thông qua IOU. Ví dụ, các thị trường tương lai HitBit và BitMEX XTZ được ra mắt trong thời gian Tezos crowdsale. Nếu có nhu cầu về BETH, chúng ta sẽ thấy một hệ sinh thái trao đổi năng động, hỗ trợ giao dịch và đặt cọc BETH. Tuy nhiên, nhu cầu về BETH có vẻ đáng nghi ngờ. BETH tạo ra khoản đầu tư kém, vì peg một chiều từ ETH sang BETH mang lại cho BETH mức giá trần là 1 ETH. Có thể nói BETH không bao giờ có thể nhiều hơn 1 ETH nhưng vẫn có giá trị.
Giai đoạn 0+ – Đặt cọc
Người dùng có thể đặt 32 BETH trên beacon chain để trở thành người xác nhận. Trong Giai đoạn 0, các trình xác nhận sẽ chỉ quản lý beacon chain. Từ Giai đoạn 1 trở đi, các trình xác nhận cũng sẽ quản lý 1.024 chuỗi shard. Beacon chain (và mỗi chuỗi shard) sẽ sử dụng Casper FFG để hoàn thiện các khối. FFG là một thuật toán Proof of Stake nhằm thực hiện cắt giảm cổ phần cho các hành vi xấu như tạm dừng chuỗi và kiểm duyệt. Những người đọc nhạy bén sẽ nhận thấy “người anh em” của FFG, Casper CBC, trong phần của “Ethereum 3.0” của lộ trình sharding.
Các staker làm gì?
Sharding nhằm mục đích phân chia (phân đoạn) thông tin trạng thái giữa các node, mà không yêu cầu bất kỳ node nào phải bao quát đầy đủ về mạng lưới. Vì vậy sẽ không có trình xác nhận nào xác nhận tất cả các shard. Thay vào đó, beacon chain sẽ phối hợp xác nhận tất cả các shard khác và tất cả các trình xác nhận sẽ xác nhận beacon chain. Mỗi epoch (64 khối hoặc khoảng 6,4 phút), beacon chain sẽ xáo trộn các trình xác nhận và gán chúng cho một shard. Một nhóm các trình xác nhận được gán cho một shard được gọi là một ủy ban (committee). Mục tiêu của ủy ban là 128 thành viên. Trong Giai đoạn 0, điều này có nghĩa là cứ sau 6 phút, beacon chain sẽ chọn các trình xác nhận có sẵn để thành lập một ủy ban trong 6 phút tiếp theo. Trong Giai đoạn 1, beacon chain sẽ chỉ định một ủy ban xác nhận cho mỗi 1.024 shard. Phương pháp chính xác cho việc này rất phức tạp. Nó liên quan đến quá trình tạo số ngẫu nhiên boa gồm nhiều giai đoạn cũng như chức năng trì hoãn có thể kiểm chứng để kìm hãm các nỗ lực thao túng quy trình lựa chọn ủy ban.
ETH2.0 chọn các ủy ban một cách ngẫu nhiên và luân chuyển các ủy ban thường xuyên vì công việc quan trọng của chúng. Các ủy ban có trách nhiệm giữ gìn sự an toàn, tính sinh động và tính toàn vẹn của shard của chúng, cũng như chứng thực cho trạng thái của shard trên chuỗi đèn hiệu. Chúng là cách duy nhất mà beacon chain có thể học được trạng thái của các shard và ngược lại. Chọn chúng ngẫu nhiên từ nhóm tất cả các trình xác nhận sẽ giảm thiểu khả năng toàn bộ ủy ban sẽ nói dối hoặc gian lận. Việc luân chuyển chúng thường nhằm mục đích giảm thiểu tác hại mà một ủy ban xấu có thể gây ra. Nói cách khác, các trình xác nhận độc hại hoặc tối đa hóa lợi nhuận sẽ khó sử dụng lựa chọn ủy ban như một công cụ để tấn công bất kỳ phần nào của mạng. Hơn nữa, nếu họ giành được quyền kiểm soát một ủy ban phân đoạn thông qua cơ hội, họ sẽ kiểm soát nó không quá 64 khối.
Bằng chứng cổ phần cho các kỹ sư
Mặc dù tài liệu về sự khác biệt về mặt triết học giữa Bằng chứng công việc (PoW) của ETH1.X và Bằng chứng cổ phần (PoS) của ETH2.0 là một quá trình vẫn đang diễn ra, đáng chú ý là một số khác biệt về tính năng PoW/PoS ảnh hưởng trực tiếp đến các kỹ sư. Ví dụ, trong khi các chuỗi PoW hỗ trợ bằng chứng SPV không trạng thái và theo dõi tóm tắt trạng thái từ xa của NiPoPow, PoS cấm mọi giao tiếp ‘trạng thái thấp’. Sự chủ quan ngăn chặn chứng thực về trạng thái. Nói cách khác, bằng chứng trạng thái từ xa trên Proof-of-Stake sẽ bao gồm cùng một lượng dữ liệu dưới dạng bằng chứng SPV không trạng thái PoW nhưng yêu cầu xác nhận trước toàn bộ lịch sử PoS. Ngược lại, bằng chứng SPV không trạng thái không cần thông tin nào khác để xác nhận. Điều này có nghĩa là các ứng dụng cross-shard hay cross-chain đã giảm chức năng và tăng chi phí trong môi trường Proof of Stake chủ quan.
Giai đoạn 1 – Sharding
Giai đoạn 1 nhằm tạo ra sự đồng thuận về nội dung của các chuỗi shard, nhưng không phải về ý nghĩa của chúng. Nói cách khác, đó là một cuộc chạy thử cho cấu trúc sharding, thay vì cố gắng sử dụng các shard để mở rộng quy mô. Beacon chain sẽ coi các khối chuỗi shard là tập hợp các bit đơn giản không có cấu trúc hoặc ý nghĩa. Chuỗi Shard sẽ chưa có tài khoản, tài sản hoặc hợp đồng thông minh. Trình xác nhận shard, được chọn ngẫu nhiên bởi beacon chain cho mỗi shard ở mỗi epoch, chỉ đơn thuần là thỏa thuận về từng nội dung của khối. Không có vấn đề gì về thông tin xuất hiện trong các khối, miễn là tất cả các ủy ban đạt được sự đồng thuận và cập nhật beacon chain trên shard thường xuyên.
Người xác nhận shard sẽ chứng thực các nội dung và trạng thái của shard thông qua một quá trình được gọi là liên kết chéo (crosslinking). Nói một cách đơn giản, ủy ban phải bao gồm thông tin có thể kiểm chứng về shard (như gốc của cây Merkle) trong beacon chain. Trong Giai đoạn 2 trở lên, liên kết chéo sẽ hỗ trợ việc trao đổi cross-shard (trao đổi/giao dịch thông tin giữa 2 shard khác nhau). Khi beacon chain đã nhận được bằng chứng về độ chính xác của liên kết chéo từ nhiều ủy ban, beacon chain có thể tin tưởng rằng liên kết chéo là đại diện trung thực của shard mà không cần phải xác nhận toàn bộ shard đó. Nếu các ủy ban không đồng ý về tính hợp lệ của liên kết chéo, rõ ràng một ủy ban bị lỗi và cần được cắt giảm. Đây là gốc rễ của an ninh cho tất cả các phân đoạn: hành vi sai trái của người xác nhận chúng cuối cùng sẽ được tìm thấy và trừng phạt bởi beacon chain.
Giai đoạn 1 không có gì đặc biệt thú vị trong đó. Về cơ bản, nó là một giai đoạn khởi động cho liên kết chéo và cơ chế đối xứng qua đó phân đoạn tham chiếu beacon chain. Các nhà thiết kế có vẻ tự tin rằng các cơ chế này sẽ hoạt động. Các câu hỏi mở lớn đều xoay quanh đặc điểm kỹ thuật và chiến lược thực hiện. Do Giai đoạn 0 đã mất khoảng hơn một năm để đạt được mức độ hợp lý về thông số kỹ thuật, tôi nghĩ rằng Giai đoạn 1 cũng sẽ mất một khoảng thời gian tương tự. Thật thú vị, việc thực hiện Giai đoạn 0 đã xảy ra đồng thời với thông số kỹ thuật. Ngay cả ngày nay, chưa đầy ba tháng kể từ testnet, thông số kỹ thuật của Giai đoạn 0 đã thay đổi thường xuyên. Điều này ngụ ý rằng các giai đoạn ETH2.0 trong tương lai sẽ có phương sai rất cao trong thời gian phát triển. Trong khi những người lạc quan đã nói với tôi là phải mất sáu tháng, thật dễ dàng để thấy Giai đoạn 1 mất 12 đến 18 tháng phát triển sau khi Giai đoạn 0 bước vào thử nghiệm.
Giai đoạn 2 – Hợp đồng thông minh
Giai đoạn 2 cuối cùng cũng mang đến một hệ thống giống như Ethereum mà chúng ta quen thuộc. Với việc phát hành Giai đoạn 2, chuỗi shard chuyển từ các thùng chứa dữ liệu đơn giản sang trạng thái chuỗi có cấu trúc. Đây là khi BETH sẽ trở nên có thể chuyển nhượng và hợp đồng thông minh sẽ được giới thiệu lại. Mỗi shard sẽ quản lý một máy ảo dựa trên eWASM (chúng ta sẽ gọi nó là “EVM2”). Chúng tôi hy vọng EVM2 sẽ hỗ trợ các tài khoản, hợp đồng, trạng thái và các khái niệm trừu tượng khác mà chúng tôi quen thuộc từ Solidity. Tuy nhiên, những thay đổi lớn phía sau hậu trường có khả năng phá vỡ hầu hết các công cụ hiện có. May mắn thay, nhóm eWASM đã thực hiện một số nền tảng cho solc, truffle và ganache. Chúng ta có thể mong đợi để xem hầu hết các công cụ quen thuộc được chuyển sang hỗ trợ EVM2 trước hoặc trong testnet của Giai đoạn 2.
Tiền thuê kho lưu trữ (State rent), rất có thể bao gồm Giai đoạn 2, đặt ra một số thách thức thú vị cho các kỹ sư Solidity ngày nay. Thay vì có thể lưu trữ code và dữ liệu vô thời hạn, tiền thuê kho lưu trữ sẽ yêu cầu các nhà phát triển hợp đồng và người dùng trả tiền cho việc lưu trữ EVM2 theo thời gian. Điều này ngăn chặn sự “phát phình” của kho lưu trữ, bằng cách đảm bảo rằng thông tin không được sử dụng rơi ra khỏi kho lưu trữ theo thời gian. Mục tiêu là làm cho người dùng, thay vì node đầy đủ, trả các chi phí của kho lưu trữ. Nhiều mô hình khác nhau đã được đề xuất, nhưng không có người chiến thắng rõ ràng.
Với việc một số kế hoạch nâng cấp Ethereum và các nhà phát triển cốt lõi Ethereum nổi bật đang khuyến nghị nó, tiền thuê kho lưu trữ có thể là sự chồng chéo duy nhất trong các lộ trình khác nhau. Do đó, tôi đặc biệt khuyên bạn nên lập kế hoạch trả tiền thuê tiền thuê kho lưu trữ cho các hợp đồng hiện đang triển khai và thiết kế các mô hình để chuyển tiền thuê kho lưu trữ cho người dùng trong tương lai. Chúng tôi không biết thiết kế chính xác của tiền thuê kho lưu trữ, nhưng chúng ta nên lập kế hoạch cho các chi phí.
Ngoài ra, chúng tôi không biết nên mong đợi những gì từ Giai đoạn 2. Nó vẫn còn trong giai đoạn nghiên cứu rất sớm và bao gồm một số vấn đề lớn chưa được giải quyết. Với đặc điểm kỹ thuật và quy trình phát triển không chính thức, cũng như phạm vi mở rộng của Giai đoạn 2 so với Giai đoạn 1, có vẻ không hợp lý khi đề xuất rằng Giai đoạn 2 có thể khởi chạy trước năm 2020. Có thể nói, trong khi ETH2.0 có thể ra mắt trong năm nay, hãy đừng vội hy vọng ETH2.0 sẽ hỗ trợ chuyển nhượng tài sản hoặc hợp đồng thông minh cho đến (ít nhất là) năm 2020.
Giai đoạn 3 – Lưu trữ trạng thái ngoài chuỗi
Bây giờ, để nói thêm về hợp đồng thông minh, chúng tôi sẽ bỏ qua gần như toàn bộ Giai đoạn 3. Giai đoạn 3 giảm thiểu trạng thái trên chuỗi bằng cách di chuyển càng nhiều chuỗi càng tốt. Thay vì chuỗi lưu trữ toàn bộ trạng thái, nó sẽ lưu trữ một số thông tin trạng thái và bộ tổng hợp (bộ tổng hợp là các bit dữ liệu ngắn biểu thị danh sách dài dữ liệu; ví dụ như cây Merkle là một loại bộ tổng hợp). Người dùng sẽ chịu trách nhiệm lưu trữ toàn bộ trạng thái ngoài chuỗi. Khi người dùng muốn tương tác với trạng thái, họ bao gồm bằng chứng về trạng thái hiện tại với giao dịch của họ. Bằng cách đó việc yêu cầu nguồn lực của việc chạy một node xác nhận có thể thấp hơn nhiều. Một số thiết kế tập hợp với các thuộc tính và đặc tính hiệu suất khác nhau được biết đến, nhưng không có cách tiếp cận nào được chọn. Tại thời điểm này, chúng tôi không còn khả năng tận dụng giao tiếp trên chuỗi để điều phối người dùng, vì vậy chúng tôi phải lên kế hoạch đồng bộ hóa trạng thái thông qua một số hệ thống khác. Các sự kiện trở nên ít hữu ích hơn đối với các kỹ sư ở đây, vì chuỗi không còn đảm bảo tính khả dụng của dữ liệu. Trong Giai đoạn 3, việc duy trì và truy xuất trạng thái ngoài chuỗi sẽ trở thành một hạn chế thiết kế quan trọng đối với các dapps.
Giai đoạn 4 – Hợp đồng được phân đoạn
Tuy nhiên, vẫn còn một vấn đề sót lại: các hợp đồng ETH2.0, mặc dù chúng sẽ mạnh mẽ như các hợp đồng Ethereum, bị ràng buộc với một phân đoạn (shard) duy nhất và không bao giờ có thể tương tác trực tiếp với các hợp đồng trên một phân đoạn khác. Đây là một hậu quả trực tiếp của sharding. Mục tiêu của Sharding là để phân chia trạng thái giữa các shard và không yêu cầu kiến thức trực tiếp về các shard khác. Nó đạt được quy mô bằng cách chia trạng thái và giảm thiểu lượng tải trên bất kỳ trình xác nhận nào. Tương tác trực tiếp đòi hỏi kiến thức trực tiếp. Theo thiết kế, một shard không có kiến thức trực tiếp về các shard khác. Nó biết về các shard khác chỉ thông qua các liên kết chéo đến beacon chain. Do đó, bất cứ khi nào chúng ta muốn tương tác chéo, chúng ta phải chờ beacon chain. Cụ thể, điều này có nghĩa là nếu SafeMath được triển khai trên Shard A, người dùng trên Shard B sẽ phải chờ để truy cập hoặc triển khai SafeMath mới trên Shard B.
Các tiện ích đơn giản như SafeMath sẽ được triển khai cho từng phân đoạn – 1024 SafeMath trên 1024 phân đoạn – nhưng còn các thị trường như Maker hay Compound thì sao? Lời hứa về tài chính có thể kết hợp trở thành thách thức để vượt qua ranh giới phân đoạn. Một sự chậm trễ lâu dài giữa việc mở CDP và nhận DAI có thể gây ra tổn thất tài chính không thể chấp nhận được. Điều gì xảy ra nếu thị trường di chuyển và CDP bị thanh lý trước khi người dùng nhận được DAI? Trên thực tế, điều này có thể có nghĩa là người dùng sẽ có tài khoản trên mỗi shard có chứa hợp đồng thông minh hấp dẫn và thành phần cross-shard bị mất hoàn toàn. Maker và 0x chỉ có thể tương tác nếu cả hai được triển khai trên cùng một shard và người dùng 0x cũng có tài sản trên shard đó.
Sự trao đổi cơ bản: đồng bộ hoặc quy mô
Các nhà thiết kế ETH2.0 không biết hệ thống trao đổi cross-shard sẽ trông như thế nào. Từ việc đọc nhiều đề xuất, có vẻ như có một sự trao đổi cơ bản giữa phản hồi ngay lập tức và dự đoán. Bản chất của sharding có thể thay đổi: người dùng phải chờ đợi việc trao đổi cross-shard bất kể điều gì. Tuy nhiên, chúng ta có thể kết hợp các giai đoạn thực hiện cục bộ và từ xa của giao dịch trên mỗi phân đoạn chặt chẽ hoặc lỏng lẻo.
Một khớp nối chặt chẽ đặt sự chờ đợi đầu tiên. Giao dịch sẽ không làm gì cho đến khi các shard đã trao đổi (truyền tải thông tin) với nhau. Ngược lại, chúng ta có thể ghép đôi giao dịch một cách lỏng lẻo bằng cách thực hiện một phần ngay lúc đó và một phần ở phía sau. Giao dịch thực hiện trên phân đoạn cục bộ và sau đó thực hiện trên phân đoạn từ xa sau khi đã trao đổi cross-shard. Khớp nối lỏng lẻo thể hiện một khuôn mặt tốt hơn cho người dùng. Họ thấy giao dịch của họ thực thi địa phương ngay lập tức và biết rằng việc thực hiện từ xa sẽ xảy ra tại một thời điểm nào đó trong tương lai. Thật không may, họ không thể biết kết quả của một giai đoạn từ xa của giao dịch lỏng lẻo mà không phải chờ đợi. Giao dịch kết hợp chặt chẽ dễ dự đoán hơn. Người dùng biết nhiều hơn về kết quả vì trạng thái từ xa không thay đổi giữa các giai đoạn thực thi cục bộ và từ xa. Tuy nhiên, khớp nối chặt chẽ đòi hỏi người dùng phải chờ đợi trước khi thấy bất kỳ kết quả nào.
Chúng tôi có rất ít thông tin về mô hình trao đổi của ETH2.0. Chúng tôi biết rằng nó có thể cung cấp các cuộc gọi hợp đồng cross-shard mà không phải hy sinh phần lớn các lợi ích mở rộng. Tôi sẽ không trách bạn nếu bạn dừng việc đọc ở đây, vì Giai đoạn 4 chỉ có bản đồ tư duy và một vài liên kết mơ hồ. Một hậu quả không rõ ràng của điều này là ETH2.0 sẽ không mang lại lợi ích mở rộng đáng kể cho các hệ thống hợp đồng thông minh phức tạp cho đến Giai đoạn 4. Cho đến lúc đó, các hợp đồng muốn tương tác với các hợp đồng khác phải tồn tại cùng với một shard và bị giới hạn ở tốc độ và quy mô của shard đó. Chúng tôi hy vọng các shard sẽ có tốc độ nhân tố không đổi nhỏ so với ETH1.X. Điều này có nghĩa là sẽ có ít lý do để di chuyển code hợp đồng thông minh hoặc người dùng cho đến khi Giai đoạn 4 được phát hành, có khả năng vào giữa những năm 2020, vì lợi thế sẽ nhỏ. Trong lúc đó, để hiểu rõ hơn về việc trao đổi cho các kỹ sư và người dùng dapp, tôi đã điều tra một vài mô hình được đề xuất và bao gồm các mô tả ngắn ở đây. Tôi không nghĩ rằng bất kỳ điều nào trong số này sẽ được thông qua, nhưng tôi tin rằng chúng rất hữu ích trong việc hiểu về sự trao đổi. Xin nhắc lại một lần nữa: tất cả mọi thứ dưới đây đều là suy đoán.
Một mô hình cơ bản: Biên lai và bằng chứng
Tất cả các hình thức trao đổi cross-chain đều tận dụng beacon chain. Bởi vì beacon chain cam kết với trạng thái của tất cả các shard và mỗi shard cam kết với trạng thái của beacon chain, chúng ta có thể sử dụng nó như một trung tâm trong hệ sinh thái chuỗi chain. Thông điệp từ chuỗi này sang chuỗi khác trong một số trường hợp phải truyền qua beacon chain. Chúng tôi không muốn gửi đầy đủ thông điệp, vì điều đó sẽ yêu cầu beacon chain tự xử lý từng giao dịch, bỏ qua toàn bộ lợi ích.
Thay vào đó, bất cứ khi nào người dùng hoặc hợp đồng trên Shard A muốn tương tác với Shard B, chúng tôi sẽ tạo cho Shard A tạo một “biên lai” giả định kèm tin nhắn. Shard A cam kết tất cả các biên lai của nó trong tiêu đề khối của nó (block header). Beacon chain chờ A hoàn tất và sau đó cam kết tiêu đề A (bao gồm cả cam kết đối với hóa đơn). Shard B phải chờ beacon quyết toán và sau đó cam kết với tiêu đề beacon. Một khi điều này đã xảy ra, một giao dịch mới có thể được gửi đến B, bao gồm biên lai và bằng chứng. Bằng chứng cho thấy rằng biên lai được bao gồm trong A, rằng A được bao gồm trong beacon và beacon được bao gồm trong B. Bằng cách này, các hợp đồng trên B có thể tin tưởng vào tin nhắn được gửi từ A. Nếu các hợp đồng trên B muốn gửi một phản hồi trở lại (có thể là giá trị trả về, hoặc lỗi), chúng tôi lặp lại toàn bộ quá trình theo chiều ngược lại: Shard B đưa ra một biên lai mà cuối cùng tìm đường trở về Shard A.
Rất dễ để biết tại sao quá trình này lại mất thời gian. Từng bước trong bốn bước trao đổi đều yêu cầu phải chờ vài phút để hoàn thiện! Thật không may, chúng ta không thể tránh được sự chờ đợi này. Nếu chúng ta muốn chắc chắn về trạng thái từ xa, thì chúng ta phải chờ đợi ở mỗi bước. Trường hợp tốt nhất cho “trao đổi khứ hồi” là bốn chu kỳ hoàn chỉnh. Điều đó nói rằng, người dùng có được sự tự tin sau ba chu kỳ vì người dùng có thể thấy biên lai của Shard B, trước khi Shard A có thể nhìn thấy chúng. Với chiều dài epoch 6,4 phút của ETH2.0, người dùng phải chờ 19 phút để xem kết quả và 26 phút để nhận kết quả trên chuỗi.
Biên lai cụ thể: Việc di chuyển các token giữa các shard
Tính linh hoạt của ERC20 token đã khiến chúng trở nên phổ biến trong Ethereum ngày nay. Tuy nhiên, ETH2.0 đặt ra một số vấn đề logic cho token. Vì hợp đồng thông minh quản lý tất cả số dư token và hợp đồng thông minh đó chỉ tồn tại trên một shard duy nhất, token từ Shard A không hề tồn tại trên Shard B. Tuy nhiên, với một vài trao đổi cross-shard thông minh, chúng tôi có thể triển khai cùng một token trên một số shard và cho phép di chuyển các token giữa các shard – thực hiện một cách hiệu quả peg hai chiều giữa các hợp đồng token.
Sơ đồ này khá đơn giản: trong lúc triển khai token của chúng tôi (hãy gọi nó là “Cool Cross-shard Token” hay “CCT”), chúng tôi sẽ sử dụng ERC20 với hai bổ sung nhỏ: migrateSend (di chuyển trong quá trình Gửi) và migrateReceive (chuyển trong quá trình Nhận). Chúng tôi sẽ có migrateSend đốt cháy token và tạo biên lai. Biên lai sẽ bao gồm số lượng token bị đốt và shard nhận được. Chúng tôi có migrateReceive xác nhận biên lai và đúc cùng số lượng CCT. Sau đó, chúng tôi sẽ triển khai hợp đồng token tương tự trên mỗi shard. Bây giờ chúng ta có thể di chuyển token giữa các shard một cách hiệu quả bằng cách ra lệnh MigrateSend để đốt cháy, và sau đó ra lệnh MigrateReceive để đúc. Chúng tôi sẽ phải triển khai lại hợp đồng token của mình trên mỗi shard, nhưng điều đó có vẻ cũng đáng để làm. Di chuyển (một chiều) mất ít nhất hai giai đoạn hữu hạn của trao đổi cross-shard. Vì vậy, sau khi chúng ta ra lệnh di chuyển, hãy chờ khoảng 10 phút trước khi CCT của chúng ta có thể sử dụng được trên phân đoạn nhận.
Yanking
Biên lai là một cách chung để di chuyển thông tin qua các shard. Chúng tôi có thể đưa bất kỳ thông tin trực tuyến nào vào biên lai. Điều này bao gồm toàn bộ hợp đồng thông minh. Yanking là một đề xuất để di chuyển hợp đồng qua các shard bằng cách bao gồm code của hợp đồng và lưu trữ trong một biên lai. Hợp đồng sẽ bị xóa (hay còn gọi là bị kéo ra – “yank”) khỏi Shard A và sau đó được triển khai lại trên Shard B sau khi biên lai di chuyển đến đó. Khi ở trên Shard B, nó có thể trao đổi trực tiếp với các hợp đồng của Shard B và tương tác với trạng thái của Shard B. Nó thậm chí có thể được kéo lại về Shard A.
Điều này sẽ cho phép bất kỳ hợp đồng thông minh nào có thể liên lạc với bất kỳ ai khác (sau thời gian chờ đợi cross-shard). Thật không may, vì biên lai bao gồm toàn bộ hợp đồng và tất cả lưu trữ của nó, nó có thể trở nên tốn kém để di chuyển các hợp đồng lớn hoặc phổ biến. Và trong khi biên lai đi qua, hợp đồng hoàn toàn không sử dụng được. Nó đã được kéo ra từ Shard A nhưng vẫn chưa đến được Shard B. Điều này có nghĩa là tất cả những người dùng khác đã bị khóa khỏi hợp đồng đó cho đến khi nó đến được Shard B. Và thậm chí sau đó, chỉ những người dùng đã sử dụng Shard B mới có thể tương tác với nó. Do đó, yanking phù hợp nhất với các hợp đồng nhỏ với ít người dùng. Nó làm cho việc thực hiện kết hợp chặt chẽ khả thi nhưng không phải là một giải pháp chung.
Ghép cặp các shard
Giờ chúng ta sẽ chuyển sang các công trình mới lạ hơn. Biên lai được thiết kế để thực hiện các trao đổi không đồng bộ (liên kết lỏng lẻo). Tuy nhiên, chúng ta cũng muốn có trao đổi đồng bộ. Đối với điều đó, chúng ta phải sáng tạo hơn một chút. Ghép cặp các shard (Shard pairings) là một thiết kế đơn giản giúp chúng ta thực hiện việc kết hợp chặt chẽ trong đó tối giản nhất những phiền toái.
Ghép cặp shard là một sơ đồ đơn giản. Được mô tả ở đoạn thứ ba của bài viết này, chúng tôi xáo trộn các shard thành các cặp đồng bộ ở mỗi độ cao. Mỗi khi một shard được ghép nối với một shard khác, người dùng của shard này có thể thực hiện các cập nhật trạng thái được kết hợp chặt chẽ trên chúng. Điều này có nghĩa là nếu Phân đoạn A và B được ghép nối ở độ cao là 7, tất cả các trình xác nhận của A và B phải biết tất cả trạng thái của A và B, và các shard phải tiến lên cùng nhau hoặc không tiến chút nào. Trong mô hình này, nếu bạn cần một giao dịch cross-chain giữa A và B, bạn sẽ đợi A và B được ghép cặp ngẫu nhiên. Vitalik mô tả trường hợp 100 shard. Với 1.024 shard, chúng tôi hy vọng nó sẽ mất 512 khối – khoảng một giờ – nhưng vì các cặp là ngẫu nhiên, nên có thể mất nhiều thời gian hơn hoặc ngắn hơn nhiều. Như Vitalik đã lưu ý, tỷ lệ này rất kém khi bạn muốn tương tác với nhiều shard.
Shard zone
Đây là một phiên bản rộng hơn của các cặp shard. Mỗi epoch chúng tôi chia các shard thành một vài “zone” (khu vực) khác nhau gồm nhiều shard. Các zone này phải tiến hành một cách đồng bộ, có nghĩa là tất cả các shard trong một zone sẽ cập nhật trạng thái cục bộ của chúng với nhau. Bằng cách tiến hành đồng bộ, các khu vực cung cấp chuyển động tự do giữa các shard và tương tác trực tiếp với bất kỳ hợp đồng nào trong zone đó, nhưng không có lợi thế nào để liên lạc với bất kỳ shard nào bên ngoài khu vực của bạn. Ngoài ra, vì các zone yêu cầu người xác nhận phải biết trạng thái của tất cả các shard ở trong zone, chúng phủ nhận nhiều lợi thế mở rộng của sharding. Nếu một zone bao gồm 16 shard, chúng tôi hy sinh khoảng 15/16 (= 94%) lợi thế quy mô trong khi đạt được sự kết hợp chặt chẽ của việc thực hiện chỉ với 15/1.024 (= 1%) trên toàn bộ mạng lưới.
Những trở ngại
Một đặc tính không rõ ràng của cross-shard (và cross-chain) đó là người dùng đạt được sự tin tưởng vào một tin nhắn nhanh hơn các chuỗi liên quan. Alice, gửi 5 BETH từ Shard A đến Shard B biết rằng nó sẽ đến ngay khi cô gửi nó. Bob, khi thấy người gửi biết rằng BETH sẽ đến Shard B ngay khi việc gửi được hoàn tất trên Shard A. Tuy nhiên, Shard B và các hợp đồng của nó phải chờ vài phút để beacon chain đạt được sự hoàn thiện về quyết toán của Shard A. Điều này ngụ ý rằng một chiếc ví tinh vi có thể chấp nhận và chi tiền cho Shard B ngay khi chúng được chi trên Shard A. Nói cách khác, Bob sẽ lấy IOU có thể thi hành từ ví của Alice trên Shard B, bởi vì Bob có độ tin cậy cao rằng Alice đã gửi đủ ETH để trang trải nó. Nếu có đủ số người dùng của Shard B sẵn sàng quan sát Shard A và chấp nhận IOU được tiêu chuẩn hóa, thì ETH của Shard A có thể được chi tiêu trên Shard B rất nhanh chóng sau khi được gửi. Tuy nhiên, sơ đồ này sẽ trở nên vô cùng phức tạp khi được áp dụng cho các hợp đồng thông minh, vì trạng thái không bao giờ có thể thay thế được, và các IOU cho trạng thái là điều không thể, vì vậy nó không phù hợp với tương tác chung. Điều này có nghĩa là chúng ta nên coi những trở ngại là một cải tiến UX trong việc ghép cặp lỏng lẻo. Nó cho phép việc ghép cặp này mô phỏng việc ghép cặp chặt chẽ với sự thực hiện nhanh chóng cho một số giao dịch.
Chia tách đồng thuận với trạng thái
Một trong những khả năng phức tạp và ‘kích thích trí tuệ’ đó là quá trình đồng thuận sẽ được tách ra khỏi quá trình cập nhật trạng thái. Ngày nay, các công cụ khai thác Ethereum và các node đầy đủ chỉ chấp nhận các khối sau khi thực hiện tất cả các cập nhật trạng thái có trong khối. Thay vào đó, họ có thể chấp nhận các khối nhưng cập nhật trạng thái sau. Trong trường hợp này, thay vì đạt được sự đồng thuận về trạng thái của hệ thống như chúng ta làm trong Ethereum, chúng ta sẽ đạt được sự đồng thuận về tổng lịch sử (hoặc tổng số đơn đặt hàng) của tất cả các giao dịch trên tất cả các shard. Việc này có nghĩa là mỗi shard có thể thêm các khối một cách nhanh chóng mà không cần biết trạng thái của bất kỳ shard nào khác, đó là cách shard tạo ra lợi thế mở rộng. Tuy nhiên, hiệu ứng của giao dịch trên toàn bộ trạng thái của shard và toàn bộ mạng lưới sẽ không được biết cho đến khi tất cả các shard đã hoàn tất. Nói cách khác, việc hoàn thiện các trạng thái khá tụt hậu so với việc hoàn thiện nội dung shard.
Từ góc độ người dùng: chúng tôi sẽ gửi giao dịch ngay lập tức và chúng tôi biết rằng chúng được bao gồm, nhưng chúng tôi phải chờ để chắc chắn về kết quả của giao dịch đó. Khi các shard hoàn thành, chúng tôi sẽ có thêm thông tin về trạng thái, nhưng không thể hoàn toàn chắc chắn cho đến khi tất cả các shard hoàn tất. Tương tự như những trở ngại, trong một số trường hợp, người dùng có thể chắc chắn về kết quả của một giao dịch trước chuỗi và hành động tương ứng.
Kết luận & Hướng dẫn kỹ thuật
ETH2.0 sẽ là một hệ thống hoàn toàn khác với Ethereum. Cả hai sẽ tồn tại song song trong nhiều năm và có các bộ tính năng rộng rãi khác nhau. Trong tương lai gần, hãy chờ đợi một peg một chiều từ ETH đến BETH. Nếu bạn điều hành một dịch vụ trao đổi hoặc lưu ký, hãy xem xét cách mà bạn có thể hỗ trợ giao dịch lưu ký BETH và đặt cược cho người dùng của mình trước khi dịch vụ này có thể chuyển nhượng được. Còn về lâu dài, hãy xem xét các hợp đồng thông minh của bạn sẽ thích ứng với các shard có và không có trao đổi cross-shard như thế nào. Trên hết, hãy theo dõi quá trình nghiên cứu và phát triển. ETH2.0 là một hệ thống phức tạp và đang phát triển. Tất cả các kỹ sư dapp cần hiểu rõ về kế hoạch và tiến độ của ETH2.0.
Ethereum đã hoãn Hard Fork, nhưng một số thợ mỏ đã không nghe
