Người sáng lập Ethereum V God đã đề xuất thay thế "RISC-V" bằng Ethereum trong lớp thực thi để thay thế EVM trong quá khứ, điều này khiến một số nhà phát triển nghi ngờ và vào năm 2016, nhà phát triển Ethereum OG tin rằng điều này sẽ khiến hệ sinh thái Ethereum phải đối mặt với sự phân phối lại và rất không thân thiện với các dự án vốn nhỏ. (Tóm tắt: Phí xử lý của Ethereum đạt mức thấp nhất trong năm năm và cộng đồng đã đặt ra "lý thuyết độc L2": không có ô tô trên đường và V God vẫn đang cười và xây dựng đường cao tốc) (Bổ sung cơ bản: Tháo dỡ tham vọng chiến lược của Vitalik để xây dựng lại lớp điều hành của Ethereum bằng "RISC-V thay vì EVM") Đề xuất "RISC-V" gần đây của người sáng lập Ethereum V God đã thu hút sự chú ý của cộng đồng tiền điện tử và gây ra cuộc tranh luận giữa các nhà phát triển hệ sinh thái cốt lõi và đối với hầu hết người dùng, hầu hết trong số họ không thể hiểu RISC-V Làm thế nào để cải cách Ethereum, và đề xuất của V-God có thể mang lại tiến bộ gì cho Ethereum? Để trả lời câu hỏi này, chúng tôi đã phỏng vấn một "con rồng chống quy mô" OG cũ, người đã phát triển hệ sinh thái cốt lõi của Ethereum từ năm 2016 và anh ta sẽ trả lời quy trình chi tiết sửa đổi "RISC-V" và các tác động tiêu cực ngắn hạn có thể xảy ra trong tương lai, nhắc nhở tất cả các nhà đầu tư Ethereum chú ý đến việc theo dõi đề xuất này. Cách cải tiến tình hình RISC-V Ethereum khác với các chuỗi PoS khác ở chỗ máy khách Ethereum bao gồm hai phần, "lớp đồng thuận" và "lớp thực thi", và lớp đồng thuận chịu trách nhiệm bỏ phiếu cổ phần đóng gói và lớp thực thi chịu trách nhiệm xử lý các giao dịch, vì vậy mã thực thi hợp đồng thông minh thực sự là một máy khách lớp thực thi được chạy bởi máy tính nút, chạy mã bằng cách lấy chương trình phát sóng giao dịch và ghi kết quả bỏ phiếu thông qua "lớp đồng thuận" trên sổ cái công khai. Cách duy nhất để nâng cấp môi trường EVM hiện tại lên RISC-V là cập nhật "máy khách lớp thực thi" của máy khách nút, chỉ là một nhánh cấp phần mềm, không giống như hard fork thông thường trong quá khứ để thay đổi khối Ethereum và bản sửa đổi nút tương ứng. Theo mô tả nội dung của bài báo của V God, lý tưởng nhất, nếu tất cả các máy khách nút đều có người thực thi RISC-V, thì hoạt động của giao thức cho phiên bản mới và hoạt động của bằng chứng zk có thể đạt được hiệu quả lý thuyết gần gấp 100 lần, nhưng phải biết rằng điều này được tính trên hợp đồng thông minh cho phiên bản RISC-V và máy khách RISC-V, liên quan đến định dạng hợp đồng thông minh EVM được thực thi trên máy khách EVM. Điều đặc biệt về đề xuất của RISC-V lần này là anh ta được cải tiến trực tiếp trên máy khách lớp điều hành và sẽ không sử dụng phần hard fork, điều mà tôi không thích lắm, nhưng có thể thấy rằng Ethereum đang di chuyển theo một hướng mới, có thể là một cạnh hai lưỡi, và mức độ thay đổi này trong quá khứ Ethereum có thể chọn được thực hiện với một hard fork, bởi vì nó có thể là một cách tiếp cận an toàn hơn. Sự tương ứng giữa tình hình hiện tại và hợp đồng cũ Sau khi hiểu được hiệu suất của lý thuyết, chúng ta hãy xem tình hình hiện tại là gì, tình hình hiện tại là tất cả các hệ sinh thái của Ethereum và tất cả các hoạt động EIP đều được thực hiện thành công thông qua các hợp đồng thông minh EVM và máy khách EVM, nếu như V God nói rằng RISC-V sẽ có bộ chuyển đổi EVM, thì tình hình thực tế trong tương lai có thể được chia thành các tình huống sau Hợp đồng thông minh EVM chạy trên máy khách EVM (EIP cũ hoàn toàn tương thích, nhưng EIP mới cần tương ứng với hai phiên bản) Hợp đồng thông minh EVM chạy trên máy khách RISC-V thông qua bộ chuyển đổi EVM của RISC-V (các EIP cũ và mới cần phải trải qua rất nhiều thử nghiệm và gỡ lỗi để giải quyết) Hợp đồng thông minh RISC-V chạy trên máy khách RISC-V (tất cả EIP cũ sẽ được kiểm tra lại, nhưng EIP mới phải hoàn toàn tương thích) Tóm lại, xem xét hiệu suất lý thuyết về hiệu quả hoạt động hợp đồng thông minh trong tương lai là 100 lần, chỉ có trạng thái thứ ba được áp dụng và đối với trường hợp thứ hai, Đặc biệt, nó dựa vào việc tối ưu hóa trình chuyển đổi của nhóm cốt lõi Ethereum, cũng như tất cả các nâng cấp EIP và hợp đồng thông minh trong quá khứ, điều đó có nghĩa là Ethereum cần phải trả một mức giá tối ưu hóa rất lớn để đạt được cải thiện hiệu suất lý thuyết và không chắc chắn liệu tối ưu hóa hiệu quả của mã EVM cũ thông qua dịch trên RISC-V chắc chắn lớn hơn so với môi trường EVM gốc. Trên thực tế, V God đã nói điều này, tôi đoán chắc hẳn có rất nhiều core developer cảm thấy rất tuyệt vọng, trước đây về phát triển EVM, để giải quyết từng EIP implementation và test, khối lượng công việc đã rất lớn, bởi vì Ethereum là một cộng đồng thích thử nghiệm các câu trả lời mở trong một môi trường rất mở. Nhưng bây giờ khi nó trở thành môi trường RISC-V, tôi chỉ nghĩ về giai đoạn thử nghiệm chuyển đổi, đó là một vấn đề rất đau đầu, vấn đề cốt lõi là bạn có thể không thể chạy hiệu quả hơn 1 ~ 5 lần so với môi trường ban đầu trong thời gian thử nghiệm, vì vậy tôi đoán thời gian thử nghiệm này sẽ tiếp tục được kéo dài nhiều lần, giống như Ethereum Merge trong quá khứ, do đó thiếu kết quả cụ thể trong giai đoạn đầu, và rất khó để thu hút các hệ sinh thái bên ngoài triển khai trên testnet và gửi phản hồi. Tôi chỉ có thể nói rằng V God có tham vọng lớn, nhưng tôi không nghĩ rằng việc triển khai là rất lạc quan, ít nhất tôi nghĩ rằng hơn một nửa số nhà phát triển cốt lõi có thể không hài lòng lắm, nếu họ quyết tâm đổi sang RISC-V, V God và Ethereum Foundation cần phải dành rất nhiều nỗ lực để khuyến khích đội ngũ phát triển cốt lõi và hệ sinh thái. Vấn đề tương ứng sinh thái với RISC-V Con rồng đề cập rằng vấn đề lớn nhất của đề xuất RISC-V có thể đến từ sự hỗ trợ và tương ứng của hệ sinh thái dự án tư nhân, trong hệ sinh thái nguồn mở hiện có, các thành phần có thể được sử dụng rất hạn chế, vì vậy khẩu hiệu dịch EVM sang RISC-V do V God đề xuất có thể có nhiều nghi ngờ và vấn đề trong ngắn hạn. Ví dụ: hệ sinh thái hiện có của Ethereum, chẳng hạn như các dự án và hợp đồng EVM không có vấn đề gì, dưới tiền đề dịch EVM sang RISC-V, có thể thiếu trạng thái hoặc chấm dứt hoạt động trong quá trình thực hiện hợp đồng ở lớp thực hiện, có nghĩa là ngay cả các dự án EVM cũ không gặp bất kỳ vấn đề nào trong quá khứ, trong trường hợp sử dụng dịch EVM sang RISC-V, có thể có các mã thông báo không thể được đề xuất hoặc vô tình bị đốt cháy hoặc khóa. Một ví dụ như vậy rất có thể khiến nhóm dự án sinh thái, trong một số trường hợp, không sẵn sàng mở cho người dùng sử dụng bộ chuyển đổi EVM sang RISC-V để chạy các hợp đồng thông minh EVM kế thừa; Ngoài ra, để tránh các rủi ro liên quan và theo dõi công nghệ mới của Ethereum, cách tốt nhất cho hệ sinh thái dự án là viết một phiên bản hợp đồng RISC-V mới cho tất cả các hợp đồng thông minh và kết nối giữa hợp đồng cũ và hợp đồng mới được giải quyết thông qua cầu nối tài sản. Trên thực tế, cách tham gia vào khả năng tương thích rất dễ đóng gói, nhưng nếu nền tảng sẵn sàng phân tán tiền để có được giải pháp chung, thì nó có thể giải quyết 99% các vấn đề tương thích, nhưng vấn đề nằm ở 1% còn lại và sự tin tưởng bảo mật của các nhà phát triển sinh thái. Bây giờ bạn hỏi các nhà phát triển dự án của Ethereum, tôi đoán tôi sẽ không quá tự tin vào phần dịch EVM RISC-V, các công ty công nghệ vốn lớn muốn thuộc về các hệ thống hoặc chip tùy chỉnh của riêng họ từ đầu đến cuối, họ sẽ không nhất thiết phải chọn RISC-V, bởi vì mặc dù kiến trúc này là mã nguồn mở, so với các kiến trúc chính thống như ARM và X86, hỗ trợ sinh thái RISC-V rất hạn chế và không có sự phát triển liên quan của blockchain, điều đó có nghĩa là Ethereum phải mở ra một thế giới bằng tay không. Nếu trong kỳ thi...
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Ethereum "cải cách RISC-V" khiến các nhà phát triển bỏ chạy? OG cảnh báo: hệ sinh thái ETH sẽ bị phân phối lại, các dự án nhỏ sẽ rời bỏ Solana
Người sáng lập Ethereum V God đã đề xuất thay thế "RISC-V" bằng Ethereum trong lớp thực thi để thay thế EVM trong quá khứ, điều này khiến một số nhà phát triển nghi ngờ và vào năm 2016, nhà phát triển Ethereum OG tin rằng điều này sẽ khiến hệ sinh thái Ethereum phải đối mặt với sự phân phối lại và rất không thân thiện với các dự án vốn nhỏ. (Tóm tắt: Phí xử lý của Ethereum đạt mức thấp nhất trong năm năm và cộng đồng đã đặt ra "lý thuyết độc L2": không có ô tô trên đường và V God vẫn đang cười và xây dựng đường cao tốc) (Bổ sung cơ bản: Tháo dỡ tham vọng chiến lược của Vitalik để xây dựng lại lớp điều hành của Ethereum bằng "RISC-V thay vì EVM") Đề xuất "RISC-V" gần đây của người sáng lập Ethereum V God đã thu hút sự chú ý của cộng đồng tiền điện tử và gây ra cuộc tranh luận giữa các nhà phát triển hệ sinh thái cốt lõi và đối với hầu hết người dùng, hầu hết trong số họ không thể hiểu RISC-V Làm thế nào để cải cách Ethereum, và đề xuất của V-God có thể mang lại tiến bộ gì cho Ethereum? Để trả lời câu hỏi này, chúng tôi đã phỏng vấn một "con rồng chống quy mô" OG cũ, người đã phát triển hệ sinh thái cốt lõi của Ethereum từ năm 2016 và anh ta sẽ trả lời quy trình chi tiết sửa đổi "RISC-V" và các tác động tiêu cực ngắn hạn có thể xảy ra trong tương lai, nhắc nhở tất cả các nhà đầu tư Ethereum chú ý đến việc theo dõi đề xuất này. Cách cải tiến tình hình RISC-V Ethereum khác với các chuỗi PoS khác ở chỗ máy khách Ethereum bao gồm hai phần, "lớp đồng thuận" và "lớp thực thi", và lớp đồng thuận chịu trách nhiệm bỏ phiếu cổ phần đóng gói và lớp thực thi chịu trách nhiệm xử lý các giao dịch, vì vậy mã thực thi hợp đồng thông minh thực sự là một máy khách lớp thực thi được chạy bởi máy tính nút, chạy mã bằng cách lấy chương trình phát sóng giao dịch và ghi kết quả bỏ phiếu thông qua "lớp đồng thuận" trên sổ cái công khai. Cách duy nhất để nâng cấp môi trường EVM hiện tại lên RISC-V là cập nhật "máy khách lớp thực thi" của máy khách nút, chỉ là một nhánh cấp phần mềm, không giống như hard fork thông thường trong quá khứ để thay đổi khối Ethereum và bản sửa đổi nút tương ứng. Theo mô tả nội dung của bài báo của V God, lý tưởng nhất, nếu tất cả các máy khách nút đều có người thực thi RISC-V, thì hoạt động của giao thức cho phiên bản mới và hoạt động của bằng chứng zk có thể đạt được hiệu quả lý thuyết gần gấp 100 lần, nhưng phải biết rằng điều này được tính trên hợp đồng thông minh cho phiên bản RISC-V và máy khách RISC-V, liên quan đến định dạng hợp đồng thông minh EVM được thực thi trên máy khách EVM. Điều đặc biệt về đề xuất của RISC-V lần này là anh ta được cải tiến trực tiếp trên máy khách lớp điều hành và sẽ không sử dụng phần hard fork, điều mà tôi không thích lắm, nhưng có thể thấy rằng Ethereum đang di chuyển theo một hướng mới, có thể là một cạnh hai lưỡi, và mức độ thay đổi này trong quá khứ Ethereum có thể chọn được thực hiện với một hard fork, bởi vì nó có thể là một cách tiếp cận an toàn hơn. Sự tương ứng giữa tình hình hiện tại và hợp đồng cũ Sau khi hiểu được hiệu suất của lý thuyết, chúng ta hãy xem tình hình hiện tại là gì, tình hình hiện tại là tất cả các hệ sinh thái của Ethereum và tất cả các hoạt động EIP đều được thực hiện thành công thông qua các hợp đồng thông minh EVM và máy khách EVM, nếu như V God nói rằng RISC-V sẽ có bộ chuyển đổi EVM, thì tình hình thực tế trong tương lai có thể được chia thành các tình huống sau Hợp đồng thông minh EVM chạy trên máy khách EVM (EIP cũ hoàn toàn tương thích, nhưng EIP mới cần tương ứng với hai phiên bản) Hợp đồng thông minh EVM chạy trên máy khách RISC-V thông qua bộ chuyển đổi EVM của RISC-V (các EIP cũ và mới cần phải trải qua rất nhiều thử nghiệm và gỡ lỗi để giải quyết) Hợp đồng thông minh RISC-V chạy trên máy khách RISC-V (tất cả EIP cũ sẽ được kiểm tra lại, nhưng EIP mới phải hoàn toàn tương thích) Tóm lại, xem xét hiệu suất lý thuyết về hiệu quả hoạt động hợp đồng thông minh trong tương lai là 100 lần, chỉ có trạng thái thứ ba được áp dụng và đối với trường hợp thứ hai, Đặc biệt, nó dựa vào việc tối ưu hóa trình chuyển đổi của nhóm cốt lõi Ethereum, cũng như tất cả các nâng cấp EIP và hợp đồng thông minh trong quá khứ, điều đó có nghĩa là Ethereum cần phải trả một mức giá tối ưu hóa rất lớn để đạt được cải thiện hiệu suất lý thuyết và không chắc chắn liệu tối ưu hóa hiệu quả của mã EVM cũ thông qua dịch trên RISC-V chắc chắn lớn hơn so với môi trường EVM gốc. Trên thực tế, V God đã nói điều này, tôi đoán chắc hẳn có rất nhiều core developer cảm thấy rất tuyệt vọng, trước đây về phát triển EVM, để giải quyết từng EIP implementation và test, khối lượng công việc đã rất lớn, bởi vì Ethereum là một cộng đồng thích thử nghiệm các câu trả lời mở trong một môi trường rất mở. Nhưng bây giờ khi nó trở thành môi trường RISC-V, tôi chỉ nghĩ về giai đoạn thử nghiệm chuyển đổi, đó là một vấn đề rất đau đầu, vấn đề cốt lõi là bạn có thể không thể chạy hiệu quả hơn 1 ~ 5 lần so với môi trường ban đầu trong thời gian thử nghiệm, vì vậy tôi đoán thời gian thử nghiệm này sẽ tiếp tục được kéo dài nhiều lần, giống như Ethereum Merge trong quá khứ, do đó thiếu kết quả cụ thể trong giai đoạn đầu, và rất khó để thu hút các hệ sinh thái bên ngoài triển khai trên testnet và gửi phản hồi. Tôi chỉ có thể nói rằng V God có tham vọng lớn, nhưng tôi không nghĩ rằng việc triển khai là rất lạc quan, ít nhất tôi nghĩ rằng hơn một nửa số nhà phát triển cốt lõi có thể không hài lòng lắm, nếu họ quyết tâm đổi sang RISC-V, V God và Ethereum Foundation cần phải dành rất nhiều nỗ lực để khuyến khích đội ngũ phát triển cốt lõi và hệ sinh thái. Vấn đề tương ứng sinh thái với RISC-V Con rồng đề cập rằng vấn đề lớn nhất của đề xuất RISC-V có thể đến từ sự hỗ trợ và tương ứng của hệ sinh thái dự án tư nhân, trong hệ sinh thái nguồn mở hiện có, các thành phần có thể được sử dụng rất hạn chế, vì vậy khẩu hiệu dịch EVM sang RISC-V do V God đề xuất có thể có nhiều nghi ngờ và vấn đề trong ngắn hạn. Ví dụ: hệ sinh thái hiện có của Ethereum, chẳng hạn như các dự án và hợp đồng EVM không có vấn đề gì, dưới tiền đề dịch EVM sang RISC-V, có thể thiếu trạng thái hoặc chấm dứt hoạt động trong quá trình thực hiện hợp đồng ở lớp thực hiện, có nghĩa là ngay cả các dự án EVM cũ không gặp bất kỳ vấn đề nào trong quá khứ, trong trường hợp sử dụng dịch EVM sang RISC-V, có thể có các mã thông báo không thể được đề xuất hoặc vô tình bị đốt cháy hoặc khóa. Một ví dụ như vậy rất có thể khiến nhóm dự án sinh thái, trong một số trường hợp, không sẵn sàng mở cho người dùng sử dụng bộ chuyển đổi EVM sang RISC-V để chạy các hợp đồng thông minh EVM kế thừa; Ngoài ra, để tránh các rủi ro liên quan và theo dõi công nghệ mới của Ethereum, cách tốt nhất cho hệ sinh thái dự án là viết một phiên bản hợp đồng RISC-V mới cho tất cả các hợp đồng thông minh và kết nối giữa hợp đồng cũ và hợp đồng mới được giải quyết thông qua cầu nối tài sản. Trên thực tế, cách tham gia vào khả năng tương thích rất dễ đóng gói, nhưng nếu nền tảng sẵn sàng phân tán tiền để có được giải pháp chung, thì nó có thể giải quyết 99% các vấn đề tương thích, nhưng vấn đề nằm ở 1% còn lại và sự tin tưởng bảo mật của các nhà phát triển sinh thái. Bây giờ bạn hỏi các nhà phát triển dự án của Ethereum, tôi đoán tôi sẽ không quá tự tin vào phần dịch EVM RISC-V, các công ty công nghệ vốn lớn muốn thuộc về các hệ thống hoặc chip tùy chỉnh của riêng họ từ đầu đến cuối, họ sẽ không nhất thiết phải chọn RISC-V, bởi vì mặc dù kiến trúc này là mã nguồn mở, so với các kiến trúc chính thống như ARM và X86, hỗ trợ sinh thái RISC-V rất hạn chế và không có sự phát triển liên quan của blockchain, điều đó có nghĩa là Ethereum phải mở ra một thế giới bằng tay không. Nếu trong kỳ thi...