Cộng đồng phát triển giao thức Ethereum đã đưa ra nhiều quyết định trong những ngày đầu của Ethereum có tác động đáng kể đến sự phát triển của dự án. Trong một số trường hợp, các nhà phát triển Ethereum đã đưa ra quyết định hợp lý và giải quyết một số vấn đề mà Bitcoin gặp phải.
Và chúng tôi đang tạo ra một cái gì đó hoàn toàn mới để hạn chế những nhược điểm hiện tại. Cũng có những lúc chúng ta cần phải đánh đổi giữa sự phức tạp và đơn giản vì chúng ta cần sự linh hoạt trong các tình huống khác nhau.
Chúng ta có nên áp dụng một phiên bản đơn giản của Proof of Stake không?
Ethereum sẽ sớm hợp nhất với Gasper Proof-of-stake rất phức tạp nhưng mạnh mẽ, với các tính năng sau:
- Xác nhận single-block một cách mạnh mẽ – Block sẽ được tạo trong vài giây khi chứa đủ các giao dịch. Nó không thể sửa đổi trừ khi một tỷ lệ lớn các node không xác minh hoặc có độ trễ mạng cực cao.
- Sự chắc chắn về kinh tế – Một khi một block được tạo thành công sẽ không sửa chữa được nên không xảy ra các vấn đề hack mất hàng triệu ETH.
- Lợi nhuận có thể dự đoán được – Validator được thưởng sau mỗi chu kỳ (6,4 phút).
- Hỗ trợ số lượng validator cao hơn – Beacon Chain Ethereum hỗ trợ hàng trăm nghìn validator.
Nhưng việc tạo ra một hệ thống với các thuộc tính này là khó, đòi hỏi nhiều năm nghiên cứu, nhiều thất bại và rất nhiều nỗ lực.
Nếu các nhà nghiên cứu của Ethreum không suy nghĩ quá nhiều về sự đồng thuận và vấn đề năng lượng, thì có lẽ Rollup sẽ được phát minh vào năm 2016.
Điều này khiến chúng tôi tự hỏi: liệu PoS có thực sự có tốt, bởi vì ngay cả một phiên bản đơn giản của PoS cũng sẽ tốt hơn nhiều so với PoW hiện tại của chúng tôi.
Nhiều người có quan niệm sai lầm Proof of Stake khá phức tạp, nhưng thực sự có nhiều thuật toán Proof of Stake đơn giản như Nakamoto PoW ví dụ như PoS của NXT ra mắt vào năm 2013. Gasper phức tạp hơn các thuật toán này đơn giản vì nó hoàn thành nhiều nhiệm vụ hơn.
Theo mình, việc áp dụng Proof of Stake ngay từ đầu không phải là điều đúng đắn để làm. PoW giúp mở rộng tính phi tập trung ban đầu, cải thiện khả năng tiếp cận của Ethereum và thúc đẩy sự phát triển của cộng đồng. Nhưng việc chuyển sang PoS đơn giản hơn sẽ bảo vệ môi trường tốt hơn đồng thời cho phép các nhà nghiên cứu tập trung tốt hơn vào các vấn đề mở rộng quy mô.
Giải mã Sharding
Kể từ khi chúng tôi bắt đầu phát triển Sharding trên Ethereum vào năm 2014, chúng tôi đã làm việc về vấn đề giải mã. Trước khi các shard phức tạp có khả năng thực thi và tích hợp giao dịch cross-shard, chúng tôi đã đơn giản hóa giao thức và chuyển nhiều trách nhiệm hơn cho người dùng (ví dụ: trong giao dịch cross-shard, người dùng phải trả phí gas cho cả hai shard).
Sau đó, chúng tôi chuyển sang một roadmap tập trung vào Rollup, từ góc độ giao thức các shard chỉ có chức năng tổng hợp dữ liệu. Cuối cùng khi kết hợp với danksharding, chúng ta có thể kết hợp thị trường phí shard thành một. Sử dụng cách này thiết kế cuối cùng trông giống như một chuỗi không bị shard.
Nhưng nếu chúng ta đi theo con đường ngược lại thì sao? Trên thực tế, các nhà nghiên cứu Ethereum đã dành rất nhiều thời gian để khám phá một hệ thống sharding phức tạp hơn: các shard sẽ trở thành chain, sub-chain phụ thuộc vào main chain theo quy tắc lựa chọn fork, các thông điệp cross-shard sẽ được định tuyến bởi giao thức, các validator shard được thay đổi xoay vòng và thậm chí các ứng dụng được tự động tải lên mạng lưới cân bằng trên các shard.
Nhìn chung ngay cả những ý tưởng rất phức tạp giúp chúng ta rất nhiều và có khả năng định hình hướng phát triển giao thức của Ethereum (thậm chí cả giao thức Layer2) trong vài năm tới.
Chúng ta nên tăng hoặc giảm chức năng trong EVM không?
Ngoài tính năng audit, đặc điểm kỹ thuật của EVM có thể được triển khai vào giữa năm 2014. Tuy nhiên, trong vài tháng tới chúng tôi đã tích cực khám phá các tính năng mới hữu ích cho blockchain DApp, như sau:
1. Chúng tôi muốn thêm một opcode POST nhưng quyết định từ bỏ. Opcode POST khiến cuộc gọi không đồng bộ không được thực hiện cho đến khi giao dịch hoàn tất.
2. Chúng tôi cũng muốn thêm một opcode ALARM nhưng sau đó đã từ bỏ. Chức năng của ALARM tương tự như POST, ngoại trừ việc nó có thể thực hiện một cuộc gọi không đồng bộ trong một block trong tương lai, cho phép hợp đồng lập kế hoạch hoạt động trước.
3. Chúng tôi đã thêm nhật ký, cho phép hợp đồng xuất ra các record không liên quan đến trạng thái nhưng có thể được đọc bằng giao diện và ví DApp. Tuy nhiên, chúng tôi cũng đã cân nhắc việc thực hiện nhật ký chuyển ETH nhưng đã từ bỏ vì chúng tôi cảm thấy "mọi người sẽ sớm chuyển sang ví hợp đồng thông minh".
4. Chúng tôi đã xem xét mở rộng SSTORE để hỗ trợ các mảng byte, nhưng đã từ bỏ những lo ngại về sự phức tạp và thiếu bảo mật của nó.
5. Chúng tôi đã thêm các hợp đồng được trước, có thể thực hiện các hoạt động Crypto cụ thể với phí gas thấp hơn EVM.
6. Trong những tháng sau khi ra mắt, chúng tôi đã cân nhắc vấn đề cho thuê trạng thái, nhưng chúng tôi đã không đưa vào do sự phức tạp của nó.
Chúng tôi đã đưa ra quyết định đúng đắn, chúng tôi thực sự không cần phải thêm opcode POST và thật khó để đảm bảo tính bảo mật của opcode ALARM (nếu mọi người đặt nó trong các block 1 đến 99999) Vậy điều gì sẽ xảy ra khi rất nhiều code được thực thi trong block thứ 100000? Block đó sẽ mất hàng giờ để xử lý code? Một số hoạt động đã lên lịch sẽ được đẩy sang các block sau không? Nếu điều này xảy ra, tính bảo mật có còn nguyên vẹn? Tính bảo mật của mảng byte SSTORE cũng khó đạt được và sẽ làm tăng kích thước nhân chứng trong trường hợp xấu nhất.
Vấn đề thuê trạng thái khó khăn hơn: Ethereum sẽ trở nên khó xây dựng hơn, mặc dù nó có thể sẽ có khả năng mở rộng và bền vững hơn. Đồng thời, kế hoạch hết hạn trạng thái của chúng tôi vào thời điểm đó thực sự tồi 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 tốt phải mất nhiều năm để đạt được và không được phép đi tắt.
Một hướng đi khác cho LOG
LOG có thể được thực hiện theo 2 cách khác nhau:
1. Chúng tôi có thể thực hiện chuyển ETH tự động đến LOG. Điều này sẽ tiết kiệm rất nhiều thời gian cho sàn giao dịch và nhiều người dùng khác nhằm giảm thiểu việc xảy ra lỗi phần mềm. Mọi người sẽ tin tưởng nhiều hơn vào LOG và ví hợp đồng thông minh sẽ được sử dụng trên quy mô lớn hơn.
2. Chúng tôi hoàn toàn có thể biến nó thành ERC mà không cần opcode LOG: Sẽ có một hợp đồng tiêu chuẩn cấu hình chức năng submitLog, có thể sử dụng công nghệ hợp đồng tiền gửi Ethereum để tính toán gốc Merkle của tất cả các log trong block. EIP-2929 hoặc lưu trữ trên block (tương đương với TSTORE) sẽ làm giảm chi phí của nó.
Chúng tôi đã nghiêm túc xem xét phương pháp thứ 1 nhưng cuối cùng đã không sử dụng nó vì nó quá phức tạp: Sử dụng opcode LOG để tạo log trực tiếp sẽ thuận tiện hơn. Chúng tôi cũng tính toán sai rằng hầu hết người dùng sẽ nhanh chóng chuyển sang ví hợp đồng thông minh và sử dụng opcode để ghi lại các chuyển khoản.
Chúng tôi đã không thực sự nghĩ về cách tiếp cận thứ 2 trước đây, nhưng nhìn lại nó thực sự khá tốt. Nhược điểm chính của nó là nó thiếu một cơ chế lọc Bloom quét log một cách nhanh chóng. Nhưng hóa ra cơ chế lọc Bloom quá chậm và không thân thiện với DApps, vì vậy ngày càng có nhiều người sử dụng TheGraph để truy vấn.
Nhìn chung một trong 2 cách tiếp cận đều làm cho mọi thứ tốt hơn. Giữ LOG ra khỏi giao thức làm cho mọi thứ đơn giản hơn, nhưng khả năng log một cách tự động tất cả các giao dịch ETH nếu nó nằm trong giao thức cũng rất hữu ích.
Cho đến ngày nay, mình sẽ ủng hộ việc loại bỏ opcode LOG trong EVM.
Điều gì sẽ xảy ra nếu EVM hoàn toàn khác?
EVM có thể chọn 2 con đường riêng biệt:
1. Làm cho EVM trở thành ngôn ngữ cấp cao hơn với các biến tích hợp, các câu lệnh IF, vòng lặp và các cấu trúc khác.
2. Làm cho EVM trở thành bản sao của một số máy ảo hiện có (LLVM, WASM,…).
Chúng tôi chưa bao giờ nghĩ về con đường đầu tiên, và nó có ưu điểm là nó đơn giản hóa trình biên dịch và cho phép nhiều nhà phát triển code trực tiếp trong EVM. Đồng thời, nó cũng có thể làm cho cấu trúc của ZK-EVM đơn giản hơn. Tuy nhiên, điểm yếu của con đường này là nó làm cho EVM code phức tạp hơn về mặt cấu trúc: Nó không còn là một danh sách opcode đơn giản, mà là một cấu trúc dữ liệu phức tạp hơn phải được lưu trữ theo một cách nhất định.
Con đường thứ hai gồm những người ủng hộ lập luận rằng nó sẽ cho phép các chương trình được biên dịch thành EVM từ các ngôn ngữ hiện có (C, Rust, v.v.) và những người phản đối lập luận cho rằng, với những hạn chế cụ thể của Ethereum, nó sẽ không thực sự cung cấp bất kỳ lợi ích nào:
1. Trình biên dịch ngôn ngữ cấp cao hiện tại có xu hướng không quan tâm đến code size trong khi blockchain code phải được tối ưu hóa rất nhiều để giảm code size trên mỗi byte.
2. Chúng tôi cần triển khai nhiều chức năng của máy ảo và xử lý nghiêm 2 chức năng không thể xử lý cùng một code theo những cách khác nhau, nhưng điều này cũng gây khó khăn cho việc thực hiện audit và xác minh trên code mà chúng tôi không viết.
3. Nếu đặc điểm kỹ thuật máy ảo thay đổi, Ethereum sẽ phải tiếp tục cập nhật nếu không sẽ rất khó để đồng bộ hóa.
Nguồn cung ETH có nên được phân phối khác đi không?
Nguồn cung ETH hiện tại có thể được mô tả qua biểu đồ từ Etherscan như sau:
Khoảng một nửa số ETH hiện đang tồn tại đã được bán trong một đợt public sale. Phần lớn ETH còn lại thì được mining. Phần màu đen ở dưới cùng, tương đương xấp xỉ 12 triệu ETH, là phần "premine" – đây là phần được phân phối cho Ethereum Foundation và khoảng 100 người đóng góp đầu tiên (early contributor) cho giao thức Ethereum.
*Premine được hiểu là việc người sáng lập ra một loại tiền mã hoá sẽ tiến hành mine một số lượng nhất định trước khi công bố cho những người khác biết.
Có 2 chỉ trích chính về quá trình này:
– Premine, cũng như thực tế về việc Ethereum Foundation đã nhận được các khoản vốn từ các đợt sale fund, là không hề "credibly neutral" (trung lập đáng tin cậy – thuật ngữ được đề xuất bởi chính Vitalik). Một số địa chỉ người nhận đã được chọn lựa một cách thủ công thông qua quy trình khép kín không công khai, và chúng ta buộc phải tin tưởng rằng quỹ Ethereum Foundation đã không tái sử dụng khoản vốn nhận được để mua lại chính lượng ETH đã bán ra, mục đích để nắm giữ nhiều ETH hơn.
– Phần Premine được thưởng quá lố cho những early contributor nhưng lại rất ít cho những contributor sau này. 75% tiền thưởng đã được chuyển đến những contributor cho công sức của họ trước cả thời điểm ra mắt, và sau khi ra mắt thì Ethereum Foundation chỉ còn giữ lại 3 triệu ETH. Trong vòng 6 tháng sau, nhu cầu bán để có thể tồn tại về mặt tài chính đã khiến lượng ETH quỹ này nắm giữ giảm xuống còn khoảng 1 triệu ETH.
Theo một cách nào đó, các vấn đề này có liên quan đến nhau: Mong muốn về việc giảm thiểu đi tính tập trung dồn vào các premine nhỏ hơn, khiến chúng nhanh chóng hụt hơi.
Đây không phải là cách duy nhất mà mọi thứ có thể được thực hiện. Zcash có một cách tiếp cận khác: Phần thưởng khối với tỷ lệ 20% không đổi sẽ được chuyển đến một nhóm người nhận mà được mã hóa cứng (hard-coded) trong giao thức, và nhóm người nhận này sẽ được tái thương lượng sau mỗi 4 năm (cho đến nay sự kiện này đã xảy ra một lần). Cách tiếp cận này bền vững hơn nhiều, tuy nhiên nó sẽ bị chỉ trích nặng nề hơn vì có tính tập trung hóa (cộng đồng Zcash có vẻ thoải mái cởi mở hơn so với cách lãnh đạo có phần kỹ trị của cộng đồng Ethereum).
Có một con đường lựa chọn thay thế khác tương tự như "DAO from day 1" mà rất phổ biến trong một số dự án defi ngày nay. Dưới đây là một đề xuất nháp được đánh giá là có khả thi:
– Chúng tôi đồng ý rằng trong 2 năm, phần thưởng khối sẽ là 2 ETH cho mỗi khối, sẽ được chuyển vào quỹ nhà phát triển.
– Bất kỳ ai mua ETH trong đợt "ether sale" đều có thể chỉ định là một quyền vote cho phân bổ ưu tiên nguồn quỹ nhà phát triển (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 được vote sẽ nhận một phần sở hữu từ quỹ nhà phát triển. Phần sở hữu này tương đương với mức trung vị của tất cả các vote, phần này được chia tỷ lệ sao cho tổng số bằng 2 ETH cho mỗi khối (Lấy số trung vị là để ngăn chặn việc tự trục lợi: 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 ít nhất một nửa số người mua khác đề cập đến bạn).
Việc bán có thể được vận hành bởi một pháp nhân mà hứa sẽ phân phối số bitcoin nhận được trong quá trình bán theo cùng một tỷ lệ với quỹ nhà phát triển ETH (hoặc bị burn, nếu chúng tôi thực sự muốn làm cho các bitcoiner hài lòng). Điều này có lẽ sẽ dẫn đến việc Ethereum Foundation nhận được nhiều vốn tài trợ hơn, và cả các nhóm không thuộc EF cũng nhận được rất nhiều nguồn vốn (dẫn đến sự phi tập trung hệ sinh thái nhiều hơn), tất cả đều không phá vỡ tính "credible neutrality – trung lập một cách đáng tin cậy" một chút nào. Tuy nhiên, nhược điểm chính tất nhiên là voting bằng coin thực sự rất tệ, nhưng thực tế, chúng ta có thể nhận thấy rằng năm 2014 vẫn là một thời điểm quá sớm và lý tưởng, những mặt trái nghiêm trọng nhất của việc voting bằng coin sẽ chỉ bắt đầu bộc lộ rất lâu sau khi đợt bán kết thúc.
Mặc dù trên thực tế, ngay cả khi quỹ phát triển hoàn toàn trung lập và đáng tin cậy nhưng những người không hài lòng với các Ethereum miner có thể sẽ di duyển sự chú ý qua DAO fork.
Chúng ta có thể học được gì từ tất cả những điều này?
Nói chung, những 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à đơn giản và một nền tảng có hiệu suất và chức năng cao để thân thiện với các nhà phát triển để họ xây dựng các ứng dụng tiên tiến.
Mong muốn của mọi người chắc hẳn muốn Ethereum đạt được cả hai tầm nhìn cùng một lúc – base layer với các thông số kỹ thuật thu hẹp dần mỗi năm và một hệ sinh thái ứng dụng nâng cao thân thiện với nhà phát triển mạnh mẽ tập trung xung quanh các giao thức layer 2. Chúng ta cần phải có một lộ trình rõ ràng và cần rất nhiều thời gian để biến nó thành hiện thực.
Trước tiên chúng ta cần kích hoạt tính năng sharding, cho phép nhiều khả năng mở rộng layer 2. Điều đó nói rằ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 đã ngăn chặn vấn đề giới hạn độ sau call stack làm giảm bớt 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 "empty accounts" tách biệt với tài khoản zero fields.
- EIP-3529 đã loại bỏ một phần của cơ chế hoàn tiền và làm cho Gas Token không còn khả thi.
