Review bài viết dài của Vitalik: Những "con đường chưa đi" của Ethereum
Tiêu đề ban đầu: "
Tiêu đề ban đầu: "The roads not taken》
Wu cho biết chuỗi khốiWu cho biết chuỗi khối
Cộng đồng phát triển Ethereum đã đưa ra nhiều quyết định trong những ngày đầu của Ethereum có tác động rất lớn đến quỹ đạo 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 có ý thức để cải thiện những điểm mà chúng tôi cho rằng bitcoin có vấn đề. Ở những nơi khác, chúng tôi đang tạo ra thứ gì đó hoàn toàn mới và chúng tôi chỉ cần nghĩ ra thứ gì đó để lấp đầy khoảng trống, nhưng có rất nhiều thứ để lựa chọn. Cũng có những lúc chúng ta cần đánh đổi giữa thứ gì đó phức tạp hơn và thứ gì đó đơn giản hơn. Đôi khi chúng ta chọn một cái gì đó đơn giản hơn, nhưng đôi khi chúng ta chọn một cái gì đó phức tạp hơn.
tiêu đề phụ
Chúng ta có nên sử dụng cơ chế PoS đơn giản hơn không?
Cơ chế Gasper PoS mà Ethereum sắp kết hợp là một hệ thống phức tạp, nhưng nó cũng là một hệ thống rất mạnh mẽ. Một số thuộc tính của nó bao gồm:
Xác nhận khối đơn rất mạnh: Sau khi một giao dịch được đưa vào một khối, thường trong vòng vài giây, khối đó sẽ được hoàn tất trừ khi một tỷ lệ lớn các nút không trung thực hoặc có độ trễ mạng cực lớn. Nó không thể bị đảo ngược.
Tính hữu hạn về mặt kinh tế: Sau khi một khối được hoàn thiện, nó không thể bị đảo ngược trừ khi kẻ tấn công có thể chịu được khoản lỗ hàng triệu ETH và bị phạt.
Phần thưởng rất dễ đoán: Người xác thực được thưởng đáng tin cậy mỗi kỷ nguyên (6,4 phút).
Hỗ trợ số lượng trình xác nhận rất cao: Không giống như hầu hết các chuỗi khác có thuộc tính trên, Ethereum Beacon Chain hỗ trợ hàng trăm nghìn trình xác thực (ví dụ: Tendermint cung cấp tính hữu hạn nhanh hơn Ethereum, nhưng nó chỉ hỗ trợ hàng trăm trình xác thực)
Nhưng việc tạo ra một hệ thống với các thuộc tính này là rất khó. Nó đòi hỏi nhiều năm nghiên cứu, nhiều năm thử nghiệm thất bại và thường là rất nhiều nỗ lực, với kết quả cuối cùng khá phức tạp.
Nếu các nhà nghiên cứu của chúng tôi không phải lo lắng nhiều về sự đồng thuận và có nhiều thời gian rảnh hơn để suy nghĩ, thì có lẽ, chỉ có thể thôi, các bản tổng hợp đã có thể được phát minh vào năm 2016. Điều này khiến chúng tôi phải suy nghĩ: liệu chúng tôi có thực sự yêu cầu các tiêu chuẩn cao như vậy đối với PoS của mình không? Bởi vì ngay cả một PoS đơn giản hơn và yếu hơn cũng sẽ là một cải tiến lớn so với hiện trạng PoW.
Nhiều người có quan niệm sai lầm rằng bản thân PoS rất phức tạp, nhưng trên thực tế có nhiều thuật toán PoS gần như đơn giản như thuật toán đồng thuận Satoshi PoW. PoS của NXT đã xuất hiện từ năm 2013 và sẽ là một ứng cử viên sẵn sàng; mặc dù nó có một số vấn đề nhưng những vấn đề đó có thể dễ dàng được vá và chúng tôi có thể có một PoS khả thi hợp lý từ năm 2017 hoặc thậm chí ngay từ đầu. Gasper phức tạp hơn các thuật toán này đơn giản vì nó đang cố gắng làm nhiều hơn chúng. Nhưng nếu chúng ta không đặt mục tiêu quá cao ngay từ đầu, chúng ta có thể bắt đầu bằng cách tập trung vào việc đạt được một số mục tiêu hạn chế hơn.
tiêu đề phụ
Giải mã phân mảnh
Ethereum sharding đã và đang di chuyển theo hướng ngày càng ít phức tạp hơn kể từ khi nghiên cứu bắt đầu vào năm 2014. Đầu tiên, chúng tôi có các phân đoạn phức tạp với các giao dịch thực thi và phân đoạn chéo được tích hợp sẵn; 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, trong đó người dùng phải trả tiền gas cho cả hai phân đoạn một cách riêng biệt; sau đó chúng tôi chuyển sang một lộ trình tập trung vào Rollup trong đó, từ góc độ giao thức, các phân đoạn chỉ là các phân đoạn dữ liệu. Cuối cùng, thông qua danksharding, thị trường phí phân đoạn được hợp nhất thành một tổng thể và thiết kế cuối cùng trông giống như một chuỗi không phải phân đoạn, nhưng ở đây, việc lấy mẫu dữ liệu sẵn có cho phép xác minh phân đoạn.
Nhưng nếu chúng ta chọn con đường ngược lại thì sao? Thực tế, có một số nhà nghiên cứu Ethereum đã đào sâu vào một hệ thống phân đoạn phức tạp hơn: các phân đoạn sẽ hoạt động như các chuỗi, sẽ có các quy tắc lựa chọn phân nhánh, trong đó các chuỗi con phụ thuộc vào chuỗi cha và các thông báo phân đoạn chéo sẽ được định tuyến bởi giao thức, trình xác nhận sẽ xoay vòng giữa các phân đoạn và thậm chí DApps sẽ tự động cân bằng tải giữa các phân đoạn.
Vấn đề với cách tiếp cận này là các dạng sharding này chủ yếu là các ý tưởng và mô hình toán học, trong khi Danksharding là một đặc điểm kỹ thuật hoàn chỉnh, gần như có thể thực hiện được. Vì vậy, với hoàn cảnh và những hạn chế của Ethereum, theo quan điểm của tôi, việc đơn giản hóa và phân biệt sharding chắc chắn là điều nên làm. Điều đó nói rằng, nghiên cứu đầy tham vọng hơn cũng đóng 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 và thậm chí những ý tưởng rất phức tạp thường có"hợp lý đơn giản"tiêu đề phụ
Lựa chọn các tính năng trong EVM
Trên thực tế, ngoại trừ kiểm toán bảo mật, đặc tả EVM về cơ bản có thể được khởi chạy vào giữa năm 2014. Tuy nhiên, trong những tháng tiếp theo vào thời điểm đó, chúng tôi tiếp tục tích cực khám phá các tính năng mới mà chúng tôi tin rằng có thể thực sự quan trọng đối với các chuỗi khối phi tập trung. Một số tính năng được thêm vào EVM, một số thì không.
Chúng tôi đã cân nhắc việc thêm một mã thao tác POST, nhưng đã quyết định không làm. Mã lệnh POST thực hiện cuộc gọi không đồng bộ và được thực thi sau khi giao dịch hoàn tất.
Chúng tôi đã cân nhắc việc thêm một opcode ALARM, nhưng đã quyết định không. ALARM hoạt động giống như một POST, ngoại trừ việc nó thực hiện lệnh gọi không đồng bộ cho một số khối trong tương lai, cho phép các hợp đồng lên lịch hoạt động.
Chúng tôi đã thêm nhật ký, cho phép các hợp đồng xuất các bản ghi không chạm vào trạng thái, nhưng có thể được giải thích bằng các giao diện và ví DApp. Điều đáng chú ý là chúng tôi cũng đã cân nhắc việc chuyển ETH phát ra nhật ký, nhưng đã quyết định không, trích dẫn"Mọi người sẽ sớm chuyển sang ví hợp đồng thông minh"。
Chúng tôi đã xem xét việc mở rộng SSTORE để hỗ trợ mảng byte, nhưng đã quyết định không sử dụng nó do những lo ngại về tính phức tạp và bảo mật.
Chúng tôi đã thêm các bản tiền biên dịch, là các hợp đồng sử dụng các triển khai gốc để thực hiện các hoạt động mã hóa chuyên biệt, rẻ hơn nhiều so với việc thực thi chúng trong EVM.
Chúng tôi đã cân nhắc về tiền thuê nhà nước trong những tháng kể từ khi ra mắt, nhưng nó chưa bao giờ được đưa vào. Nó quá phức tạp. Các kế hoạch hết hạn trạng thái tốt hơn đang được tích cực khám phá ngày nay, mặc dù việc xác thực không trạng thái và phân tách người đề xuất/người xây dựng (PBS) có nghĩa là hiện tại nó có mức độ ưu tiên thấp hơn nhiều.
Ngày nay, hầu hết các quyết định không thêm chức năng hóa ra lại là những quyết định rất đúng đắn. Không có lý do rõ ràng để thêm opcode POST. Các opcode ALARM thực sự khó triển khai một cách an toàn: điều gì xảy ra nếu mọi người trong khối 1...9999 đặt ALARM và thực thi rất nhiều mã ở khối 100.000? Khối đó sẽ mất hàng giờ để xử lý? Một số hoạt động theo lịch trình sẽ được đẩy sang các khối sau này? Nhưng nếu điều đó xảy ra, thì ALARM có đảm bảo gì không? Rất khó để thực hiện an toàn một SSTORE của các mảng byte và sẽ mở rộng đáng kể kích thước nhân chứng trong trường hợp xấu nhất.
tiêu đề phụ
Các lựa chọn thay thế cho LOG
LOG có thể được thực hiện theo hai cách khác nhau.
Chúng tôi có thể thực hiện chuyển ETH tự động gửi NHẬT KÝ. Điều này sẽ tiết kiệm cho các sàn giao dịch và nhiều người dùng khác rất nhiều nỗ lực và các vấn đề về lỗi phần mềm, đồng thời sẽ đẩy nhanh sự phụ thuộc của mọi người vào LOG, điều này sẽ giúp ích cho việc áp dụng ví hợp đồng thông minh.
Chúng ta hoàn toàn có thể làm mà không cần LOG opcode và biến nó thành ERC: sẽ có 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 tiền gửi Ethereum để tính toán gốc Merkle của tất cả nhật ký trong khối. EIP-2929 hoặc bộ lưu trữ trên toàn khối (tương đương với TSTORE, nhưng bị xóa sau khối) sẽ làm cho điều này rẻ hơn.
Chúng tôi đã xem xét kỹ lưỡng lựa chọn đầu tiên, nhưng đã từ chối nó. Lý do chính là việc ghi nhật ký chỉ đến từ LOG opcode, điều này dễ dàng hơn. Chúng tôi cũng đã kỳ vọng rất sai lầm 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í này có thể sử dụng rõ ràng opcode để ghi lại các lần chuyển.
Chúng tôi đã không xem xét lựa chọn thứ hai, nhưng khi nhìn lại, nó thực sự là một lựa chọn. Nhược điểm chính của phương pháp thứ hai là thiếu cơ chế lọc Bloom (bộ lọc Bloom) để quét nhanh nhật ký. Nhưng hóa ra cơ chế lọc Bloom quá chậm và không thân thiện với DApps nên hiện nay ngày càng có nhiều người sử dụng TheGraph cho các truy vấn.
Nhìn chung, bất kỳ cách tiếp cận nào trong số này đều có tiềm năng vượt trội so với hiện trạng. Không có trong NHẬT KÝ sẽ khiến mọi thứ trở nên đơn giản hơn, nhưng sẽ hữu ích hơn nếu tự động ghi lại tất cả các lần chuyển ETH nếu có trong NHẬT KÝ.
tiêu đề phụ
Điều gì sẽ xảy ra nếu EVM hiện tại đi theo một con đường hoàn toàn khác?
Lúc đầu, EVM có hai con đường rất khác nhau để lựa chọn:
Làm cho EVM trở thành ngôn ngữ cấp cao hơn, với các cấu trúc tích hợp sẵn như biến, câu lệnh if, vòng lặp, v.v.
Biến EVM 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 hấp dẫn của con đường này là nó có thể làm cho trình biên dịch trở nên đơn giản hơn và cho phép nhiều nhà phát triển viết mã trực tiếp hơn trong EVM. Nó cũng có thể làm cho cấu trúc của ZK-EVM đơn giản hơn. Điểm yếu của cách tiếp cận này là nó làm cho mã EVM phức tạp hơn về mặt cấu trúc: nó không còn là một danh sách mã đơn giản nữa mà là một cấu trúc dữ liệu phức tạp hơn phải được lưu trữ bằng cách nào đó. Đó là, chúng tôi đã bỏ lỡ một cơ hội để có được những điều tốt nhất của cả hai thế giới: một số thay đổi EVM có thể mang lại cho chúng tôi rất nhiều lợi ích, trong khi vẫn giữ nguyên cấu trúc EVM cơ bản: vô hiệu hóa các bước nhảy động, thêm một số mã lệnh được thiết kế để hỗ trợ các chương trình con (nếu không, hãy xem: EIP -2315), chỉ cho phép truy cập bộ nhớ trên ranh giới từ 32 byte, v.v.
Con đường thứ hai đã được đề xuất và từ chối nhiều lần. Lập luận ủng hộ nó thường là nó sẽ cho phép các chương trình được biên dịch từ các ngôn ngữ hiện có (C, Rust, v.v.) sang EVM. Lập luận phản biện luôn là, với những hạn chế duy nhất của Ethereum, nó không thực sự mang lại bất kỳ lợi ích nào:
Trình biên dịch cho các ngôn ngữ cấp cao hiện có thường không quan tâm đến tổng kích thước mã, trong khi mã blockchain phải được tối ưu hóa rất nhiều để giảm từng byte kích thước mã.
Chúng tôi cần nhiều triển khai của máy ảo và yêu cầu nghiêm ngặt rằng không có hai triển khai nào xử lý cùng một mã theo cách khác nhau. Việc kiểm tra và xác minh bảo mật đối với mã mà chúng tôi không viết sẽ khó hơn.
Nếu thông số kỹ thuật của VM thay đổi, Ethereum sẽ phải luôn cập nhật theo nó hoặc ngày càng trở nên không đồng bộ.
tiêu đề phụ
Nguồn cung ETH có nên được phân phối theo cách khác không?
Nguồn cung cấp ETH hiện tại có thể được biểu thị đại khái bằng biểu đồ Etherscan này:
Khoảng một nửa số ETH hiện được bán trong Ethereum Public Sale, nơi bất kỳ ai cũng có thể gửi BTC đến địa chỉ Bitcoin và phân bổ nguồn cung cấp ETH ban đầu được tính toán thông qua tập lệnh mã nguồn mở. Hầu hết phần còn lại về cơ bản cũng đã được khai thác. 12 triệu ETH màu đen được đánh dấu là "khác" thực sự là phần được khai thác trước, số tiền được phân phối giữa Ethereum Foundation và khoảng 100 người đóng góp ban đầu cho giao thức Ethereum.
Có hai lời chỉ trích chính về quá trình này:
Cả hoạt động khai thác trước và Quỹ Ethereum chịu trách nhiệm cung cấp dịch vụ công khai đều không có tính trung lập đáng tin cậy. Một số địa chỉ người nhận được chọn thủ công thông qua quy trình khép kín, Ethereum Foundation phải được tin cậy để không tận dụng thêm tiền bán công khai thông qua các khoản vay để có thêm ETH (chúng tôi không và không ai tuyên bố chúng tôi có, nhưng ngay cả yêu cầu được tin cậy cũng bị xúc phạm một số người).
Phần thưởng cho những người đóng góp sớm quá nhiều, để lại quá ít cho những người đóng góp sau. 75% số tiền khai thác trước được sử dụng để thưởng cho công việc của những người đóng góp trước khi trực tuyến và sau khi trực tuyến, Ethereum Foundation chỉ còn lại 3 triệu ETH. Trong vòng 6 tháng, nhu cầu bán để tồn tại đã làm giảm lượng cổ phiếu xuống còn khoảng 1 triệu ETH.
Theo một cách nào đó, những vấn đề này có liên quan với nhau: mong muốn giảm thiểu nhận thức về tập trung hóa đã góp phần tạo ra các tiền khai thác nhỏ hơn, nhưng các tiền khai thác nhỏ hơn tiêu hao nhanh hơn.
Đây không phải là giải pháp duy nhất. Zcash thực hiện một cách tiếp cận khác: 20% phần thưởng khối cố định được phân bổ cho một nhóm người nhận được mã hóa cứng trong giao thức được thương lượng lại bốn năm một lần (cho đến nay, điều này đã xảy ra một lần). Điều này sẽ bền vững hơn, nhưng nó sẽ bị chỉ trích gay gắt hơn vì quá tập trung (cộng đồng Zcash dường như chấp nhận sự lãnh đạo của các nhà công nghệ một cách cởi mở hơn so với cộng đồng Ethereum).
Một đường dẫn thay thế khả thi tương tự như đường dẫn phổ biến trong một số dự án DeFi hiện nay"DAO from day 1"tuyến đường. Đây là một đề xuất có thể có của người rơm:
Chúng tôi đồng ý phân bổ 2 ETH từ mỗi phần thưởng khối cho quỹ phát triển trong 2 năm.
Bất kỳ ai mua ETH trong đợt bán công khai Ethereum đều có thể bỏ phiếu cho việc phân bổ quỹ phát triển yêu thích của họ (ví dụ:"Trong mỗi phần thưởng khối, 1ETH được trao cho Ethereum Foundation, 0,4ETH được trao cho nhóm nghiên cứu Consensys và 0,2ETH được trao cho Vlad Zamfir..."）
Những người nhận được bình chọn sẽ nhận được một phần quỹ phát triển bằng với trung bình phiếu bầu của mỗi người, được chia theo tỷ lệ với tổng số bằng 2ETH mỗi khối (trung bình là để ngăn tự giao dịch: nếu bạn bỏ phiếu cho chính mình, bạn sẽ không nhận được gì ít hơn, trừ khi bạn nhậ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ông khai 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 công khai theo tỷ lệ tương tự như quỹ phát triển ETH (hoặc đốt chúng, nếu chúng tôi thực sự muốn giữ cho những người chơi bitcoin hài lòng). Điều này có thể dẫn đến nhiều khoản tài trợ cho Ethereum Foundation và rất nhiều khoản tài trợ cho các nhóm không phải Ethereum Foundation (dẫn đến hệ sinh thái phân cấp nhiều hơn), tất cả đều không làm suy yếu tính trung lập đáng tin cậy dù chỉ một chút. Tất nhiên, nhược điểm chính là việc bỏ phiếu mã thông báo thực sự rất tệ, nhưng về mặt thực tế, chúng ta có thể nhận ra rằng năm 2014 vẫn còn sớm và được lý tưởng hóa, và nhược điểm tồi tệ nhất của việc bỏ phiếu mã thông báo sẽ diễn ra rất lâu sau khi đợt bán công khai kết thúc.
tiêu đề phụ
Chúng ta có thể học được gì từ tất cả những điều này?
Nói chung, đôi khi tôi cảm thấy rằng thách thức lớn nhất của Ethereum đến từ việc cân bằng hai tầm nhìn: một chuỗi khối coi trọng tính bảo mật và tính đơn giản, và một nền tảng chức năng và hiệu suất cao để xây dựng các ứng dụng nâng cao. Nhiều ví dụ ở trên chỉ là một khía cạnh: chúng ta giống Bitcoin hơn với ít tính năng hơn hay chúng ta thân thiện với nhà phát triển hơn với nhiều tính năng hơn? Chúng tôi lo lắng về việc tài trợ cho nhà phát triển trở nên trung lập hơn, giống Bitcoin hơn hay chúng tôi lo lắng về việc đảm bảo các nhà phát triển được thưởng đủ để làm cho Ethereum tốt hơn ngay từ đầu?
Ướ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. Một lớp cơ sở có thông số kỹ thuật mỗi năm nhỏ hơn so với năm trước và một hệ sinh thái mạnh mẽ thân thiện với nhà phát triển gồm các ứng dụng nâng cao xoay quanh giao thức Lớp 2. Điều đó có nghĩa là, sẽ mất nhiều thời gian để đạt được một thế giới lý tưởng như vậy và có thể giúp ích rất nhiều cho chúng ta khi nhận ra rõ ràng hơn rằng điều này sẽ mất nhiều thời gian và chúng ta cần xem xét việc lập kế hoạch lộ trình từng bước.
Ngày nay, có nhiều thứ chúng ta không thể thay đổi, nhưng cũng có nhiều thứ chúng ta vẫn có thể thay đổi và vẫn có một con đường vững chắc để cải thiện chức năng và sự đơn giản. Đôi khi đường dẫn rất quanh co: trước tiên chúng ta cần thêm một số độ phức tạp để kích hoạt phân đoạn, từ đó cho phép nhiều khả năng mở rộng của lớp 2 ở trên cùng. Điều đó nói rằng, việc giảm độ phức tạp là có thể 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 của ngăn xếp cuộc gọi trở nên không cần thiết, giảm mối lo ngại về bảo mật cho các nhà phát triển hợp đồng.
EIP-161 tách khái niệm "tài khoản rỗng" khỏi tài khoản có trường bằng 0.
EIP-3529 loại bỏ một số cơ chế hoàn trả, khiến mã thông báo Gas không còn khả thi.
Các ý tưởng đang được triển khai, chẳng hạn như cây Verkle, thậm chí còn giảm độ phức tạp hơn nữa. Nhưng làm thế nào để cân bằng tốt hơn hai tầm nhìn này trong tương lai là một câu hỏi mà chúng ta nên bắt đầu suy nghĩ tích cực hơn.
