Suy nghĩ về những điều sau: Hãy tưởng tượng rằng chúng ta có OP_CAT và nó thực sự mang lại cho chúng ta khả năng introspection, STARKs + khả năng mang trạng thái (để xây dựng rollups, validiums, v.v.), hoặc thậm chí các opcode khác giải quyết nó một cách gọn gàng hơn (chọn OP_TXHASH, OP_CCV, OP_MERKLEBRANCHVERIFY, OP_STARK_VERIFY, OP_M31ADD, OP_M31SUB, OP_M31MUL, OP_M31INV, <chèn các opcode số học 64-bit ở đây>) L2 lý tưởng cho Bitcoin sẽ trông như thế nào? Điều chúng ta không muốn làm: lặp lại kịch bản Ethereum—200 đội cạnh tranh xây dựng các L2 khác nhau, kết nối kém/có thể kết hợp tất cả cạnh tranh cho cùng một người dùng, chúng ta *MUỐN* làm gì? Những bài học nào chúng ta có thể học từ Ethereum? Hãy nhớ rằng chúng ta không thể (và cũng không muốn) làm rollups dựa trên. L1 quá chậm cho điều đó, và chúng ta không muốn MEV lớp cơ bản theo kiểu đó. Cũng hãy nhớ rằng chúng ta muốn: - Hệ thống giao dịch TPS cao (Lightning không có kênh về cơ bản) - Một số sẽ muốn nhiều biểu cảm hơn (cho các khoản vay stablecoin không tin cậy, hoán đổi AMM, kho tiền, kế hoạch thừa kế, sản phẩm đòn bẩy) Hai loại hệ thống này có nên tồn tại trên cùng một lớp thực thi, hay tốt nhất là tách biệt thanh toán khỏi ứng dụng với các hàng đợi sắp xếp khác nhau (tôi có xu hướng tin như vậy) — có lẽ chúng ta muốn đi theo hướng Celestia-ish làm một zkVM L2 và tất cả các hệ thống khác như L3s, hàng đợi riêng biệt nhưng tổng hợp qua L2. Làm rollups thực sự cho bất cứ điều gì ở quy mô lớn về cơ bản là không thể cho tầm nhìn cuối cùng do thông lượng thấp của L1 và nhu cầu DA (và thêm blobs dường như rất khó xảy ra) vì vậy chúng ta có khả năng sẽ chạy một số loại validiums + lớp DA bên ngoài, zk-plasmas hoặc kiến trúc dựa trên xác thực phía khách hàng như Miden. Ngoài ra, chúng ta nên khám phá liệu chúng ta muốn hệ thống ZK thuần túy hay chứng minh lai ("optimistic ZK", xem Fuel để tham khảo) để tối đa hóa thông lượng hơn nữa. Một cách là để thị trường tự do thắng và chỉ xem điều gì xảy ra, nhưng đó là điều Ethereum đã làm. Ngay cả khi chúng ta mang theo các bài học và các đội cố gắng phối hợp xung quanh các giải pháp tổng hợp đơn lẻ từ đầu, không có gì đảm bảo rằng nó sẽ hoạt động. Chúng ta cũng không có khả năng nào để ghi nhận bất kỳ lớp thực thi cụ thể nào qua L1. Tuy nhiên, rõ ràng với tôi rằng STARKs là con đường tốt nhất cho tất cả những điều sau: - Thanh toán tối thiểu tin cậy (không có kênh, định tuyến hoặc yêu cầu thanh khoản) - Biểu cảm (cho những người muốn) - Bảo mật (VM bảo mật ZK đầy đủ) - Đạt được tất cả những điều trên mà không giới thiệu bất kỳ giả định mật mã kỳ lạ nào, thiết lập tin cậy, v.v. Bạn có thể hỏi về tính cuối cùng vì độ trễ của L1, nhưng theo tôi nó có thể được giải quyết một cách rõ ràng đến mức độ hài lòng với các sequencer được liên kết cho các pre-confs nhanh. Vậy chúng ta có tất cả các công cụ, chúng ta làm gì để sắp xếp kết quả tốt nhất có thể? Trong khi BTC rõ ràng nên là tiền tệ cho tất cả các hệ thống này (và trả phí/gas), có câu hỏi cuối cùng (hoặc có lẽ đầu tiên) về cách đạt được tất cả điều này mà không giới thiệu một token L2 chủ yếu được kiểm soát bởi một Foundation với quá nhiều quyền kiểm soát. Tôi nghĩ một hệ thống chỉ thanh toán có thể hoạt động tốt mà không cần token quản trị (chỉ với sắp xếp trung tâm + thoát đơn phương chống lại kiểm duyệt), nhưng tôi nghi ngờ điều đó cho bất cứ điều gì biểu cảm. Trong khi hầu hết các Foundation/DAO có mục tiêu phân quyền, đặt quá nhiều quyền lực vào tay một tổ chức tập trung ngay cả trong giai đoạn khởi động dường như không tối ưu đối với tôi nếu chúng ta muốn một cách tiếp cận tập thể nào đó từ đầu để giảm thiểu rủi ro phân mảnh. Sẽ rất tuyệt nếu nghe ý kiến từ những người có kinh nghiệm từ các hệ sinh thái khác như Ethereum, Celestia, Polygon, Cosmos và cũng tò mò về cách các đội L2 hiện tại đang làm việc trên Bitcoin nghĩ về những câu hỏi này (ví dụ: Alpen, Chainway, Starkware). Xin vui lòng tham gia bình luận!