Vitalik: những con đường đã không được chọn cho Ethereum
Đội phát triển giao thức Ethereum đã đưa ra rất nhiều quyết định trong giai đoạn đầu của dự án, có tác động to lớn đến sự phát triển sau này. Một số quyết định được lựa chọn nhằm giải quyết một cách có ý thức những điểm mà theo chúng tôi là cần cải thiện của Bitcoin. Ở một số trường hợp khác, chúng tôi tạo ra những thứ hoàn toàn mới, và đơn giản là cần tìm ra một thứ gì đó để điền vào chỗ trống - giữa rất nhiều lựa chọn. Và trong một số quyết định, chúng tôi buộc phải lựa chọn giữa việc thiết kế một giải pháp phức tạp hay đơn giản. Đôi khi, phương án đơn giản được lựa chọn, nhưng đôi lúc, một phương án phức tạp lại là lựa chọn tốt hơn.
Bài đăng này sẽ xem xét lại một số “ngã ba” quyết định kiểu này theo trí nhớ của tôi. Nhiều trong số những tính năng được liệt kê dưới đây đã được thảo luận nghiêm túc trong vòng phát triển cốt lõi; một số đáng ra nên được xem xét nhưng đã bị bỏ qua và không được cân nhắc một chút nào. Dù sao đi chăng nữa, việc thử tượng tưởng một Ethereum khác có thể được phát triển như thế nào vẫn là thú vị và đáng quý để có những bài học cho tương lai.
Chúng tôi có nên sử dụng một phiên bản proof of stake đơn giản hơn không?
Gasper proof of stake sắp được hợp nhất với Ethereum là một hệ thống phức tạp nhưng rất mạnh mẽ. Một số đặc tính của nó bao gồm:
Khả năng xác thực (confirmation) khối đơn rất mạnh - ngay khi giao dịch được đưa vào một khối, thường chỉ tốn vài giây để khối đó được củng cố (solidified) đến mức không thể đảo ngược hoàn nguyên (revert) trừ khi một phần lớn các node không trung thực hoặc độ trễ mạng quá cao.
Tính kinh tế hoàn thiện (economic finallity) - một khi một khối được hoàn thiện, nó không thể bị đảo ngược nếu kẻ tấn công không tiêu tốn hàng triệu ETH.
Phần thưởng xác định - validators được đảm bảo sẽ nhận phần thưởng mỗi epoch (6,4 phút), giảm động lực tạo nhóm để tăng khả năng tìm block (pool)
Hỗ trợ số lượng validators cao - không giống như hầu hết các chuỗi khác có các tính năng trên, chuỗi beacon Ethereum hỗ trợ hàng trăm nghìn validators (ví dụ: Tendermint cung cấp tốc độ hoàn thành (finality) nhanh hơn Ethereum, nhưng nó chỉ hỗ trợ vài trăm validators)
Việc tạo ra một hệ thống có đầy đủ những đặc tính này là vô cùng thử thách. Đội phát triển đã mất nhiều năm nghiên cứu, nhiều năm thất bại, và hao tổn rất nhiều công sức. Kết quả cuối cùng chúng tôi đưa ra có độ phức tạp rất cao.
Nếu các nhà nghiên cứu của chúng tôi không phải bận tâm quá nhiều về cơ chế đồng thuận, thì có lẽ, có lẽ thôi, rollups đã sớm được phát minh vào năm 2016. Điều này đưa chúng ta đến một câu hỏi: liệu chúng tôi có thực sự nên đặt tiêu chuẩn cao như vậy cho Proof of Stake hay không, khi tại thời điểm đó ngay cả một phiên bản đơn giản hơn và yếu hơn của nó cũng đã một bước cải tiến lớn so với Proof of Work?
Nhiều người có quan niệm sai lầm rằng Proof of Stake vốn là phức tạp từ căn gốc, nhưng trên thực tế, có rất nhiều thuật toán Proof of Stake đơn giản gần như Nakamoto PoW. NXT proof of stake đã tồn tại từ năm 2013 và đương nhiên là một phương án tốt; mặc dù nó có vài vấn đề, những vấn đề đó có thể dễ dàng được sửa chữa và chúng tôi có thể đạt được một giao thực Proof of Stake hoạt động tốt từ năm 2017 hoặc thậm chí ngay từ đầu. Lý do tại sao Gasper phức tạp hơn các thuật toán này chỉ đơn giản là nó cố gắng hoàn thành nhiều hơn. Nếu đặt mục tiêu khiêm tốn hơn từ đầu, thì trước tiên chúng tôi có thể tập trung vào việc đạt được một số mục tiêu ngắn hạn trước.
Ý tưởng Proof of Stake ngay từ đầu đã là một sai lầm (theo ý kiến của tôi); PoW rất hữu ích trong việc mở rộng phân phối phát hành (issuance distribution) và khiến cho Ethereum thân thiện hơn, cũng như khuyến khích cộng đồng hăng say. Việc chuyển sang một giao thức Proof of Stake đơn giản hơn vào năm 2017, hoặc thậm chí năm 2020, đã có thể giảm thiểu tác động đến môi trường (và tâm lý chống tiền điện tử do tác động của nó đến môi trường) cho phép nhiều tài nguyên nghiên cứu được đổ vào việc mở rộng quy mô hơn. Liệu sau cùng chúng tôi có phải dành nhiều nguồn lực để cải thiện Proof of Stake? Câu trả lời là có. Nhưng ngày càng có khả năng rằng chúng tôi vẫn sẽ làm điều này, dù sao đi chăng nữa.
Việc đơn giản hóa sharding (phân đoạn)
Ethereum sharing đã diễn tiến theo một quỹ đạo nhất quán là trở nên ngày càng ít phức tạp hơn kể từ khi ý tưởng được bắt đầu thực hiện vào năm 2014. Sharding của những phiên bản đầu tiên là rất phức tạp với built-in execution (thực thi tích hợp) và giao dịch phân đoạn chéo (cross-shard transactions). Sau đó, chúng tôi đơn giản hóa giao thức bằng cách chuyển nhiều trách nhiệm hơn cho người dùng (ví dụ: trong một giao dịch chéo phân đoạn, người dùng sẽ phải thanh toán riêng cho gas trên cả hai phân đoạn). Sau đó, chúng tôi chuyển sang lộ trình tập trung vào roll-up (roll-up centric map), theo quan điểm của giao thức, các phân đoạn chỉ là các binary large objects (blobs) of data. Cuối cùng, với danksharding, các loại phí phân đoạn được hợp nhất thành một và thiết kế cuối cùng trông giống như một chuỗi không phân đoạn mà trong đó một số phép thuật lấy mẫu thử tính khả dụng dữ liệu (data availability sampling) được thực hiện phía sau cánh gà giúp việc xác minh phân đoạn được diễn ra.
Nhưng điều gì sẽ xảy ra nếu chúng ta chọn đi con đường ngược lại? Chà, thực tế, một số nhà nghiên cứu Ethereum đã dành nhiều công khám phá một hệ thống sharding phức tạp hơn nhiều: các phân đoạn sẽ là các chuỗi (chain), các chuỗi con phụ thuộc vào chuỗi mẹ theo một số quy tắc nhất định, các thông điệp phân đoạn chéo sẽ được định tuyến bởi giao thức, validators sẽ được luân chuyển giữa các phân đoạn và thậm chí các applications sẽ tự động được cân bằng tải giữa các phân đoạn!
Vấn đề của cách tiếp cận này là: những hình thức sharding này phần lớn chỉ là ý tưởng và mô hình toán học, trong khi Danksharding là một thông số kỹ thuật hoàn chỉnh và gần như sẵn sàng để triển khai. Do đó, xét trên hoàn cảnh và những giới hạn lúc đó của Ethereum, việc đơn giản hóa và giảm bớt mục tiêu tham vọng của sharding, theo quan điểm của tôi, hoàn toàn là một bước đi đúng đắn. Nhưng như vậy cũng có nghĩa là, nghiên cứu chuyên sâu cũng có một vai trò rất quan trọng: nó xác định các hướng nghiên cứu đầy hứa hẹn, bởi ngay cả những ý tưởng rất phức tạp cũng thường có một phiên bản "đơn giản hợp lý" mà vẫn mang lại nhiều lợi ích và rất có thể rằng nó sẽ ảnh hưởng đáng kể đến sự phát triển giao thức của Ethereum (hoặc thậm chí là giao thức lớp 2) trong những năm tới.
Nên có nhiều hay ít đi các tính năng trong EVM?
Trên thực tế, các đặc điểm kỹ thuật của EVM về cơ bản, ngoại trừ kiểm toán bảo mật (security auditing), đã có thể ra mắt vào giữa năm 2014. Tuy nhiên, trong vài tháng sau đó, chúng tôi vẫn tích cực khám phá các tính năng khác mà chúng tôi cho rằng là thực sự quan trọng đối với một blockchain decentralized app. Một số không thực sự được triển khai, một số đã đi vào thực tế.
Chúng tôi cân nhắc thêm POST opcode, nhưng sau cùng đã quyết định bác bỏ nó. Opcode POST yêu cầu một lệnh không đồng bộ, lệnh gọi này sẽ được thực thi sau khi những phần còn lại của giao dịch đã kết thúc.
Chúng tôi cân nhắc thêm ALARM opcode, nhưng sau cùng đã quyết định bác bỏ nó. ALARM sẽ hoạt động giống như POST, ngoại trừ việc yêu cầu một lệnh gọi không đồng bộ trong một số block trong tương lai, cho phép các hợp đồng có thể lên lịch hoạt động.
Chúng tôi đã thêm nhật ký (logs), cho phép các hợp đồng xuất ra các bản ghi không chạm vào trạng thái, nhưng có thể được đọc bằng các giao diện và ví dapp. Đáng chú ý, chúng tôi cũng đã cân nhắc khiến việc chuyển ETH tạo ra một log, nhưng sau cùng lại đã quyết định bác bỏ nó với lý do là "mọi người sẽ sớm chuyển sang ví hợp đồng thông minh thôi".
Chúng tôi xem xét việc mở rộng SSTORE để hỗ trợ mảng byte (byte arrays), nhưng quyết định không thực hiện vì lo ngại về độ phức tạp và an toàn.
Chúng tôi đã thêm tiền biên dịch (precompiles), các hợp đồng thực hiện các hoạt động mật mã chuyên biệt với thực thi gốc (native implementation) với chi phí gas rẻ hơn nhiều so với thực hiện trong EVM.
Trong những tháng ngay sau khi ra mắt, state rent (thuê trạng thái) đã được xem xét đi xem xét lại nhưng không bao giờ được thực hiện. Đơn giản chỉ vì nó quá phức tạp. Ngày nay, có rất nhiều lược đồ hết hạn trạng thái (state expiry schemes) đang được tích cực khám phá, mặc dù xác thực không trạng thái (stateless verification) và tách biệt người đề xuất/người xây dựng (proposer/builder separation) khiến cho nó trở thành một phương án có mức độ ưu tiên thấp hơn nhiều.
Ngày nay, khi cân nhắc lại các quyết định này, các quyết định không thêm chức năng vào EVM hầu hết là những quyết định đúng đắn. Không có lý do đáng kể để thêm POST opcode. ALARM opcode thực sự rất khó triển khai một cách an toàn: điều gì sẽ xảy ra nếu mọi người trong khối từ 1 đến 99999 đặt ALARM để thực thi rất nhiều code ở khối 100000? Khối đó có thể sẽ tốn hàng giờ để xử lý? Liệu một số hoạt động đã lên lịch có bị đẩy trở lại các khối sau này không? Nếu điều đó xảy ra, thì điều gì đảm bảo rằng ALARM hoạt động được? SSTORE cho byte array là rất khó thực hiện một cách an toàn và sẽ làm gia tăng số lượng trường hợp hợp xấu nhất (worst-case) một cách đáng kể.
State rent (thuê trạng thái) thậm trí còn mạng đến nhiều thách thức hơn: nếu chúng tôi thực sự triển khai một số loại state rent từ ngày đầu tiên, chúng tôi sẽ không có một hệ sinh thái hợp đồng thông minh phát triển xung quanh giả định thông thường về trạng thái liên tục. Ethereum sẽ khó xây dựng hơn, nhưng nó mang đến khả năng mở rộng tốt hơn và bền vững hơn. Đồng thời, các lược đồ hết hạn trạng thái mà chúng tôi thực hiện ở thời điểm đó thực sự tệ hơn nhiều so với những gì chúng tôi có bây giờ. Đôi khi, những ý tưởng hay phải mất nhiều năm để thành hiện thực và chẳng có cách nào tốt hơn là chờ đợi nó.
Các lựa chọn thay thế cho LOG
LOG có thể được triển khai khác đi theo hai cách sau:
Chúng tôi có thể đã quy định việc chuyển ETH tự động sinh ra một LOG. Điều này sẽ giúp tiết kiệm rất nhiều công sức và giải quyết các vấn đề về lỗi phần mềm cho các sàn giao dịch và nhiều người dùng khác, đồng thời giúp gia tăng sự phụ thuộc vào log của người dùng, điều mà trớ trêu thay lại giúp đẩy nhanh việc chấp nhận sử dụng ví smart contract.
Chúng tôi có thể đã hoàn toàn không tạo ra LOG opcode, và thay vào đó biến nó thành ERC: một hợp đồng tiêu chuẩn có chức năng submitLog và sử dụng kỹ thuật của hợp đồng gửi Ethereum (Ethereum deposit contract) để tính toán gốc Merkle của tất cả các bản ghi trong khối đó có thể đã được sử dụng. Nhưng ngay cả EIP-2929 và bộ nhớ trong phạm vi khối (block-scoped storage) (tương đương với TSTORE, chỉ khác là sẽ bị xóa sau khối) cũng không thể khiến phương án này trở nên đủ rẻ.
Chúng tôi đã rất cân nhắc (1), nhưng lựa chọn bác bỏ nó. Lý do chính là để cho đơn giản: sẽ là dễ dàng hơn để logs (nhật ký) chỉ đến từ LOG opcode. Chúng tôi cũng kì vọng (một cách sai lầm) rằng hầu hết người dùng sẽ nhanh chóng chuyển sang dùng ví smart contract, cho phép ghi nhật ký chuyển khoản một cách rõ ràng bằng cách sử dụng opcode.
Lựa chọn 2. đã không được xem xét tại thời điểm đó, nhưng hiện tại khi nhìn lại, nó cũng là một lựa chọn hợp lý. Nhược điểm chính của lựa chọn (2) là thiếu cơ chế bộ lọc Bloom để quét nhanh các logs. Nhưng hóa ra, cơ chế bộ lọc Bloom dẫu sao cũng quá chậm để thân thiện với người dùng đối với dapp, và vì vậy, ngày càng nhiều người sử dụng TheGraph để truy vấn.
Nhìn chung, có lẽ một trong hai cách tiếp cận này đều vượt trội hơn so với hiện trạng. Giữ LOG bên ngoài giao thức sẽ giúp mọi thứ đơn giản hơn, nhưng nếu nó ở bên trong giao thức, việc ghi nhật ký tự động (auto-logging) đối với tất cả các giao dịch chuyển ETH sẽ khiến nó trở nên hữu ích hơn.
Ở thời điểm hiện tại, tôi có thể sẽ ủng hộ việc loại bỏ hoàn toàn LOG khỏi EVM.
Điều gì sẽ xảy ra nếu EVM là một cái gì đó hoàn toàn khác?
Có hai con đường tự nhiên rất khác nhau mà EVM có thể thực hiện:
Biến EVM trở thành một ngôn ngữ cấp cao hơn, với các cấu trúc tích hợp cho các biến, câu lệnh if, vòng lặp, v.v.
Biến EVM trở thành bản sao của một số máy ảo hiện có (LLVM, WASM, v.v.)
Con đường đầu tiên chưa bao giờ thực sự được xem xét. Điểm lợi thế của con đường này là nó có thể làm cho các compliers trở nên đơn giản hơn và cho phép nhiều nhà phát triển viết code trực tiếp trong EVM. Nó cũng có thể khiến cho việc xây dựng ZK-EVM trở nên đơn giản hơn. Điểm yếu của đường con đường này là nó sẽ làm cho cấu trúc code phức tạp hơn: thay vì là một danh sách các opcodes đơn giản liên tiếp, nó có thể là một cấu trúc dữ liệu phức tạp hơn và phải được lưu trữ bằng cách nào đó. Điều đó có nghĩa rằng, chúng tôi đã bỏ lỡ một cơ hội cải tiến tốt hơn cho cả 2 bên: một vài thay đổi EVM có thể mang lại rất nhiều lợi ích đó trong khi vẫn cơ bản giữ nguyên được cấu trúc EVM như: cấm các bước nhảy động (dynamic jumps) và thêm một opcodes được thiết kế để hỗ trợ các quy trình phụ (subroutines) (xem thêm: EIP-2315), chỉ cho phép truy cập bộ nhớ với hạn mức 32-byte word, v.v.
Lựa chọn thứ hai được đề xuất nhiều lần và cũng bị từ chối nhiều lần. Lí do thường được đưa ra là bởi nó cho phép các chương trình compile từ các ngôn ngữ hiện có (C, Rust, v.v.) vào EVM. Lập luận phản đối nó cũng chỉ ra rằng, với điều kiện lúc đó của Ethereum, nó sẽ không thực sự mang lại bất kỳ lợi ích nào:
Các compilers hiện tại từ các ngôn ngữ cấp cao có xu hướng không quan tâm đến tổng kích thước code, trong khi code blockchain phải tối ưu hóa rất nhiều để cắt giảm từng byte kích thước code.
Chúng tôi sẽ cần nhiều implementations trên VM với một yêu cầu bắt buộc là hai implementation không bao giờ xử lý cùng một code theo những cách khác nhau. Việc kiểm tra bảo mật và xác minh điều đối với phần code mà chúng tôi không viết sẽ khó hơn nhiều.
Nếu đặc điểm kỹ thuật của máy ảo thay đổi, Ethereum sẽ phải luôn cập nhật cùng với nó hoặc ngày càng mất đồng bộ hơn.
Do đó, khó có con đường nào khả thi khiến EVM có thể trở nên khác đáng kể so với hiện tại, mặc dù có rất nhiều chi tiết nhỏ hơn (bước nhảy, 64 so với 256 bit, v.v.) có thể được cải tiến để mang đến kết quả tốt hơn nhiều.
Nguồn cung cấp ETH có nên được phân phối khác không?
Nguồn cung ETH hiện tại được đại diện gần đúng bằng biểu đồ này từ Etherscan:
Khoảng một nửa số ETH tồn tại ngày nay đã được bán trong một đợt bán ether, nơi bất kỳ ai cũng có thể gửi BTC đến một địa chỉ bitcoin chuẩn hóa và việc phân phối nguồn cung ETH ban đầu được tính toán bởi một open-source script thực hiện quét blockchain Bitcoin để tìm các giao dịch đến địa chỉ đó. Phần lớn số ETH còn lại đã được đào. Phần ở dưới cùng, 12 triệu ETH được đánh dấu "Khác" (Other), là "khoản đào trước" (premined) - được phân phối cho Ethereum Foundation và ~ 100 người đóng góp ban đầu cho giao thức Ethereum.
Có hai chỉ trích chính về quá trình này:
Khoản đào trước, cũng như việc Tổ chức Ethereum nhận được tiền bán ETH, không trung lập một cách đáng tin cậy. Một số địa chỉ người nhận đã được chọn thủ công thông qua một quy trình khép kín và Ethereum Foundation cần chứng minh họ đã không cho vay số tiền nhận được từ sales để quay trở lại đợt sales, mang lại cho chính nó nhiều ETH hơn (chúng tôi đã không làm vậy và cũng không có ai tuyên bố nghiêm túc rằng chúng tôi đã làm thế, nhưng yêu cầu chứng minh này đã làm phật lòng một số người).
Khoản đào trước chia thưởng quá nhiều cho người đóng góp sớm, để lại quá ít cho những người đóng góp sau này. 75% số tiền định được dùng để thưởng cho những người đóng góp trước khi ra mắt nên sau khi ra mắt Ethereum Foundation chỉ còn lại 3 triệu ETH. Trong vòng 6 tháng, con số tiếp tục giảm xuống còn khoảng 1 triệu ETH để đảm bảo chúng tôi có thể tồn tại về mặt tài chính.
Theo một cách nào đó, các vấn đề là liên quan đến nhau: mong muốn giảm thiểu sự tập trung dẫn tới một khoản đào trước nhỏ hơn, và khoản đào trước nhỏ hơn nghĩa là nó sẽ bị rút cạn nhanh chóng hơn.
Đây không phải là cách thực hiện duy nhất. Zcash có một cách tiếp cận khác: một lượng 20% phần thưởng khối (block reward) không đổi sẽ được chuyển đến một nhóm người nhận được mã hóa cứng trong giao thức và nhóm người nhận thưởng có thể được điều chỉnh lại sau mỗi 4 năm (cho đến nay việc này đã được thực hiện một lần). Điều này lẽ ra sẽ bền vững hơn nhiều, nhưng nó cũng sẽ bị chỉ trích nặng nề hơn bởi tính tập trung (cộng đồng Zcash có vẻ thoải mái cởi mở hơn với sự lãnh đạo kỹ trị (technocratic) hơn cộng đồng Ethereum).
Một con đường thay thế có thể tương tự như "DAO từ ngày 1" phổ biến trong một số dự án Defi ngày nay. Đây là một đề xuất khả thi:
Chúng tôi đồng ý rằng trong 2 năm, một phần thưởng khối trị giá 2 ETH trên khối sẽ được chuyển vào quỹ nhà phát triển.
Bất kỳ ai mua ETH trong đợt bán ether đều có thể có một phiếu bầu cho việc phân phối quỹ nhà phát triển theo ý muốn của họ (ví dụ: "1 ETH mỗi khối cho Ethereum Foundation, 0,4 ETH cho nhóm nghiên cứu của Consensys, 0,2 ETH cho Vlad Zamfir ..." )
Những người nhận được bỏ phiếu để nhận được một phần từ quỹ nhà phát triển bằng với số phiếu trung bình của mọi người, được chia tỷ lệ để tổng số thưởng bằng 2 ETH mỗi khối (việc tính trung bình là để ngăn chặn việc tự bầu cho bản thân: nếu bạn bỏ phiếu cho chính mình, bạn sẽ không nhận được gì trừ khi bạn có được ít nhất một nửa số người mua khác đề cập đến bạn)
Việc tổ chức sales có thể được điều hành bởi một pháp nhân hứa hẹn sẽ phân phối số bitcoin nhận được trong quá trình bán hàng theo cùng tỷ lệ với quỹ nhà phát triển ETH (hoặc burn nó, nếu chúng tôi thực sự muốn những người sở hữu bitcoin hài lòng). Điều này có lẽ sẽ dẫn đến việc Ethereum Foudation nhận được nhiều tiền tài trợ, các nhóm không thuộc EF cũng nhận được rất nhiều tiền (dẫn đến phân cấp hệ sinh thái nhiều hơn), tất cả đều không phá vỡ tính trung lập đáng tin cậy một chút nào. Tất nhiên, nhược điểm chính là việc bỏ phiếu bằng coin rất tệ, nhưng thực tế, chúng ta có thể nhận ra rằng năm 2014 vẫn là một thời điểm sớm và lý tưởng, những mặt trái nghiêm trọng nhất của việc bỏ phiếu bằng coin sẽ chỉ xuất hiện rất lâu sau khi đợt bán hàng kết thúc.
Đây có phải là một ý tưởng tốt hơn và tạo ra một tiền lệ tốt hơn không? Có lẽ! Mặc dù trên thực tế, ngay cả khi quỹ phát triển hoàn toàn trung lập, những người đang chỉ trích cơ chế phân phối ETH ngày hôm nay có lẽ còn chỉ trích mạnh mẽ gấp đôi về DAO fork.
Chúng ta có thể học được gì từ tất cả những điều này?
Nhìn chung, đôi khi tôi cảm thấy thách thức lớn nhất của Ethereum đến từ việc cân bằng giữa hai tầm nhìn - một blockchain thuần túy và đơn giản, coi trọng sự an toàn và sự đơn giản, với một nền tảng có hiệu suất và chức năng cao để xây dựng các ứng dụng tiên tiến. Nhiều ví dụ ở trên chỉ là các khía cạnh của vấn đề này: chúng ta nên có ít tính năng hơn và giống Bitcoin hơn, hay nhiều tính năng hơn và thân thiện hơn với nhà phát triển? Chúng ta có lo lắng nhiều về việc làm cho nguồn tài trợ phát triển trở nên trung lập và giống Bitcoin hơn hay chúng ta chỉ lo lắng trước hết về việc đảm bảo các nhà phát triển được thưởng đủ để làm cho Ethereum trở nên tuyệt vời?
Ước mơ cá nhân của tôi là cố gắng đạt được cả hai tầm nhìn cùng một lúc - lớp cơ sở (base layer) nơi yêu cầu kỹ thuật (specification) trở nên nhỏ gọn hơn mỗi năm so với năm trước đó và một hệ sinh thái ứng dụng nâng cao thân thiện với nhà phát triển tập trung xung quanh các giao thức lớp 2. Nhưng, để đạt được một hiện thực lý tưởng như vậy đòi hỏi một khoảng thời gian dài, nhưng việc nhận thức rõ ràng hơn rằng việc thực hiện nó sẽ mất nhiều thời gian và chúng tôi cần suy nghĩ về lộ trình từng bước có lẽ đã giúp ích cho chúng tôi rất nhiều.
Ngày nay, có rất nhiều thứ chúng ta không thể thay đổi, nhưng có nhiều thứ chúng ta vẫn có thể làm được, và vẫn còn một con đường vững chắc mở ra để cải thiện chức năng và sự đơn giản hóa. Đôi khi chúng tôi sẽ phải đi một con đường vòng: trước tiên chúng ta cần phức tạp hóa hệ thống để đảm bảo tính năng sharding, từ đó mở ra rất nhiều khả năng mở rộng lớp 2 ở trên cùng. Nhưng việc giảm độ phức tạp là có thể thực hiện được và lịch sử của Ethereum đã chứng minh điều này:
EIP-150 đã làm cho giới hạn độ sâu lệnh stack (the call stack depth limit) không còn phù hợp nữa, giảm bớt những lo lắng về bảo mật cho các nhà phát triển hợp đồng.
EIP-161 đưa ra khái niệm "tài khoản trống" (empty account) như một thứ gì đó tách biệt với tài khoản có các trường bằng 0 không còn tồn tại.
EIP-3529 đã loại bỏ một phần của cơ chế hoàn tiền và làm cho gas tokens không còn khả thi.
Các ý tưởng trong hệ thống, như cây Verkle, giảm độ phức tạp hơn nữa. Nhưng câu hỏi làm thế nào để cân bằng hai tầm nhìn tốt hơn trong tương lai vẫn là câu hỏi mà chúng ta nên bắt đầu suy nghĩ tích cực ngay từ bây giờ.
Hết bài dịch.
Bài viết cho thấy rằng từ lý thuyết và những thứ có thể làm được, đến thực tiễn và lắp ghép các mảnh (nên có) thành Ethereum như chúng ta đã thấy là quá trình cực kỳ khó khăn, tốn nhiều thời gian và nguồn lực. Sản phẩm là một bức tranh hoàn chỉnh của nhiều mảnh ghép Lego, chỉ cần sai hoặc lệch một mảnh nào đó thì chúng ta sẽ không nhìn thấy sản phẩm “như nó là”.
Bản dịch bởi Nguyễn Thuý Ngọc (BA, FPT Blockchain Lab)
Hiệu đính và đăng tải: Paven Do
If You love the post, you may wish to donate for this special charity: https://www.carryforwardvietnam.org/donate/
Nếu bạn thích bài viết, bạn có thể đóng góp cho dự án từ thiện: https://www.carryforwardvietnam.org/donate/