Tác giả gốc: Kyle Samani, Đối tác tại Multicoin Capital

Tổng hợp gốc: Luffy, Tin tức tầm nhìn xa

Trong hai năm qua, cuộc tranh luận về khả năng mở rộng blockchain đã tập trung vào chủ đề trọng tâm là “mô-đun hóa và tích hợp”.

Lưu ý rằng các cuộc thảo luận về tiền điện tử thường kết hợp các hệ thống đơn lẻ và tích hợp. Cuộc tranh luận kỹ thuật về hệ thống tích hợp và hệ thống mô-đun đã kéo dài40 năm lịch sử lâu dài. Không còn là một cuộc tranh luận mới, cuộc trò chuyện này trong không gian tiền điện tử sẽ được đóng khung qua lăng kính giống như lịch sử.

Khi xem xét tính mô-đun so với tích hợp, quyết định thiết kế quan trọng nhất mà blockchain có thể đưa ra là mức độ mà nó thể hiện sự phức tạp của ngăn xếp đối với các nhà phát triển ứng dụng. Khách hàng của blockchain là các nhà phát triển ứng dụng, vì vậy các quyết định thiết kế cuối cùng cần được xem xét theo quan điểm của họ.

Ngày nay, tính mô-đun phần lớn được ca ngợi là cách chính để mở rộng quy mô của blockchain. Trong bài đăng này, tôi sẽ đặt câu hỏi về giả định này từ những nguyên tắc đầu tiên, làm sáng tỏ những huyền thoại văn hóa và những chi phí tiềm ẩn của hệ thống mô-đun, đồng thời chia sẻ kết luận của tôi sau khi suy nghĩ về cuộc tranh luận này trong sáu năm qua.

Hệ thống mô-đun tăng độ phức tạp phát triển

Cho đến nay, chi phí tiềm ẩn lớn nhất của các hệ thống mô-đun là sự phức tạp gia tăng của quá trình phát triển.

Các hệ thống mô-đun làm tăng đáng kể độ phức tạp mà các nhà phát triển ứng dụng phải quản lý, cả trong bối cảnh ứng dụng của chính họ (độ phức tạp về kỹ thuật) và trong bối cảnh tương tác với các ứng dụng khác (độ phức tạp xã hội).

Trong bối cảnh tiền điện tử, về mặt lý thuyết, các chuỗi khối mô-đun cho phép chuyên môn hóa cao hơn, nhưng phải trả giá bằng việc tạo ra sự phức tạp mới. Sự phức tạp này (cả về bản chất kỹ thuật và xã hội) đang được chuyển sang các nhà phát triển ứng dụng, cuối cùng khiến việc xây dựng ứng dụng trở nên khó khăn hơn.

Ví dụ: hãy xem xét OP Stack. Tính đến thời điểm hiện tại, nó dường như là framework mô-đun phổ biến nhất. OP Stack buộc các nhà phát triển phải chọn áp dụng Law of Chains(điều này giới thiệu rất nhiều sự phức tạp về mặt xã hội), hoặc phân nhánh và quản lý riêng biệt. Cả hai tùy chọn đều gây ra sự phức tạp đáng kể ở hạ lưu cho người xây dựng. Nếu bạn chọn phân nhánh, liệu bạn có nhận được hỗ trợ kỹ thuật từ những người chơi khác trong hệ sinh thái (CEX, fiat onramp, v.v.), những người phải chịu chi phí để tuân thủ các tiêu chuẩn công nghệ mới không? Nếu bạn chọn tuân theo Luật Xiềng xích, những quy tắc và ràng buộc nào sẽ áp đặt lên bạn hôm nay và ngày mai?

Nguồn: Mô hình OSI

Hệ điều hành hiện đại (OS) là những hệ thống phức tạp lớn chứa hàng trăm hệ thống con. Các hệ điều hành hiện đại xử lý các lớp 2-6 trong sơ đồ trên. Đây là một ví dụ cổ điển về việc tích hợp các thành phần mô-đun để quản lý mức độ phức tạp của ngăn xếp mà các nhà phát triển ứng dụng phải đối mặt. Các nhà phát triển ứng dụng không muốn giải quyết bất kỳ điều gì bên dưới lớp 7, đó là lý do tại sao hệ điều hành tồn tại: hệ điều hành quản lý độ phức tạp của các lớp bên dưới để các nhà phát triển ứng dụng có thể tập trung vào lớp 7. Do đó, tính mô-đun không phải là mục đích tự thân mà là phương tiện để đạt được mục đích.

Mọi hệ thống phần mềm chính trên thế giới hiện nay—phụ trợ đám mây, hệ điều hành, công cụ cơ sở dữ liệu, công cụ trò chơi, v.v.—đều được tích hợp cao độ và bao gồm đồng thời nhiều hệ thống con mô-đun. Các hệ thống phần mềm có xu hướng được tích hợp cao để tối đa hóa hiệu suất và giảm độ phức tạp trong quá trình phát triển. Điều này cũng đúng với blockchain.

Ngẫu nhiên, Ethereum đang giảm bớt sự phức tạp nảy sinh trong kỷ nguyên phân tách Bitcoin 2011-2014. Những người ủng hộ tính mô đun thường nhấn mạnh mô hình Kết nối hệ thống mở (OSI), lập luận rằng tính khả dụng của dữ liệu (DA) và việc thực thi nên được tách biệt; tuy nhiên, lập luận này bị hiểu lầm rộng rãi. Sự hiểu biết đúng đắn về vấn đề hiện tại sẽ dẫn đến kết luận ngược lại: OSI là một lập luận cho một hệ thống tích hợp chứ không phải là một hệ thống mô-đun.

Chuỗi mô-đun không thể thực thi mã nhanh hơn

Theo thiết kế, định nghĩa chung về chuỗi mô-đun là sự tách biệt giữa tính khả dụng của dữ liệu (DA) và việc thực thi: một bộ nút chịu trách nhiệm về DA, trong khi một bộ (hoặc các bộ) nút khác chịu trách nhiệm thực thi. Bộ sưu tập nút không nhất thiết phải có bất kỳ sự chồng chéo nào, nhưng chúng có thể.

Trong thực tế, việc tách DA và thực thi vốn không cải thiện hiệu suất của cả hai; thay vào đó, một số phần cứng ở đâu đó trên thế giới phải thực thi DA và một số phần cứng ở đâu đó phải triển khai thực thi. Việc tách các chức năng này không cải thiện hiệu suất của bất kỳ chức năng nào trong số chúng. Mặc dù việc phân tách có thể giảm chi phí tính toán nhưng nó chỉ có thể giảm được thông qua việc thực thi tập trung.

Xin nhắc lại: Bất kể kiến ​​trúc mô-đun hay kiến ​​trúc tích hợp, một số phần cứng ở đâu đó phải thực hiện công việc và việc tách DA và thực thi trên phần cứng riêng biệt vốn không giúp tăng tốc hoặc tăng tổng công suất hệ thống.

Một số người cho rằng tính mô-đun cho phép nhiều EVM chạy song song theo kiểu Tổng hợp, cho phép thực thi theo quy mô theo chiều ngang. Mặc dù điều này đúng về mặt lý thuyết, nhưng quan điểm này thực sự nhấn mạnh những hạn chế của EVM với tư cách là bộ xử lý đơn luồng, thay vì tiền đề cơ bản về việc tách DA và thực thi trong bối cảnh mở rộng thông lượng tổng thể của hệ thống.

Chỉ riêng tính mô-đun không cải thiện được thông lượng.

Tính mô đun làm tăng chi phí giao dịch cho người dùng

Theo định nghĩa, mỗi L1 và L2 là một sổ cái tài sản độc lập với trạng thái riêng. Các phần trạng thái riêng biệt này có thể giao tiếp, mặc dù có độ trễ giao dịch dài hơn và các tình huống phức tạp hơn đối với nhà phát triển và người dùng (thông qua các cầu nối chuỗi chéo như LayerZero và Wormhole).

Càng có nhiều sổ cái tài sản, trạng thái toàn cầu của tất cả các tài khoản càng bị phân mảnh. Điều này thật đáng sợ đối với các chuỗi và người dùng trên nhiều chuỗi. Sự phân mảnh của nhà nước có thể gây ra một loạt hậu quả:

• Thanh khoản giảm dẫn đến độ trượt giao dịch cao hơn;

• Tổng mức tiêu thụ Gas nhiều hơn (các giao dịch xuyên chuỗi yêu cầu ít nhất hai giao dịch trên ít nhất hai sổ cái tài sản);

• Tăng tính toán kép của sổ cái tài sản chéo (do đó làm giảm tổng thông lượng của hệ thống): Khi giá ETH-USDC thay đổi trên Binance hoặc Coinbase, cơ hội chênh lệch giá sẽ xuất hiện trên mỗi nhóm ETH-USDC của tất cả các sổ cái tài sản (bạn có thể dễ dàng hình dung Một thế giới mà mỗi khi giá ETH-USDC di chuyển trên Binance hoặc Coinbase, sẽ có hơn 10 giao dịch trên các sổ cái tài sản khác nhau. Giữ giá ổn định ở trạng thái phân mảnh là việc sử dụng không gian khối cực kỳ kém hiệu quả).

Điều quan trọng là phải nhận ra rằng việc tạo thêm sổ cái tài sản sẽ làm tăng đáng kể chi phí trên tất cả các khía cạnh này, đặc biệt là khi nó liên quan đến DeFi.

Đầu vào chính của DeFi là trạng thái trên chuỗi (tức là ai sở hữu tài sản nào). Khi các nhóm khởi chạy chuỗi ứng dụng/tổng ​​hợp, họ tự nhiên tạo ra sự phân mảnh trạng thái, điều này rất bất lợi cho DeFi, cho dù đó là nhà phát triển quản lý độ phức tạp của ứng dụng (cầu nối, ví, độ trễ, MEV chuỗi chéo, v.v.) hay người dùng ( Trượt giá, thanh toán chậm trễ).

Các điều kiện lý tưởng nhất cho DeFi là: tài sản được phát hành trên một sổ cái tài sản duy nhất và được giao dịch trong một máy trạng thái duy nhất. Càng có nhiều sổ cái tài sản, các nhà phát triển ứng dụng càng phải quản lý phức tạp hơn và chi phí cho người dùng càng cao.

Bản tổng hợp ứng dụng sẽ không tạo cơ hội kiếm tiền mới cho nhà phát triển

Những người ủng hộ AppChain/Rollup lập luận rằng các biện pháp khuyến khích sẽ thúc đẩy các nhà phát triển ứng dụng phát triển Rollups thay vì xây dựng trên L1 hoặc L2 để các ứng dụng có thể tự nắm bắt giá trị MEV. Tuy nhiên, suy nghĩ này là sai lầm, vì việc chạy một bản tổng hợp ứng dụng không phải là cách duy nhất để đưa MEV trở lại mã thông báo lớp ứng dụng và cũng không phải là cách tốt nhất trong hầu hết các trường hợp. Mã thông báo lớp ứng dụng chỉ cần mã hóa logic trong hợp đồng thông minh trên chuỗi phổ quát để thu MEV trở lại mã thông báo của riêng chúng. Hãy xem xét một vài ví dụ:

• Thanh lý: Nếu một Hợp chất hoặc Aave DAO muốn nắm bắt một phần MEV chuyển sang bot thanh lý, họ chỉ cần cập nhật các hợp đồng tương ứng để một phần phí hiện đang chảy vào người thanh lý sẽ chuyển đến DAO của riêng họ, không có chuỗi mới /Yêu cầu tổng hợp .

• Oracles: Token Oracle có thể nắm bắt MEV bằng cách cung cấp các dịch vụ chạy ngược. Ngoài việc cập nhật giá, oracle có thể được kết hợp với bất kỳ giao dịch trực tuyến tùy ý nào được đảm bảo chạy ngay sau khi cập nhật giá. Do đó, các nhà tiên tri có thể nắm bắt MEV bằng cách cung cấp các dịch vụ chạy ngược cho người tìm kiếm, người xây dựng khối, v.v.

• Khai thác NFT: Khai thác NFT có đầy rẫy các bot mở rộng quy mô. Điều này có thể dễ dàng giảm thiểu bằng cách mã hóa việc phân phối lại lợi nhuận đang giảm dần. Ví dụ: nếu ai đó cố gắng bán lại NFT của họ trong vòng hai tuần kể từ khi khai thác, 100% doanh thu sẽ quay trở lại nhà phát hành hoặc DAO. Tỷ lệ phần trăm này có thể thay đổi theo thời gian.

Không có câu trả lời chung cho việc thu MEV vào mã thông báo lớp ứng dụng. Tuy nhiên, chỉ cần suy nghĩ một chút, các nhà phát triển ứng dụng có thể dễ dàng lấy MEV trở lại thành token của riêng họ trên Universal Chain. Việc ra mắt một chuỗi hoàn toàn mới đơn giản là không cần thiết và gây ra sự phức tạp bổ sung về mặt kỹ thuật và xã hội cho các nhà phát triển, đồng thời khiến người dùng đau đầu hơn về ví và thanh khoản.

Tổng hợp ứng dụng không thể giải quyết tắc nghẽn ứng dụng chéo

Nhiều người tin rằng AppChains/Rollups sẽ đảm bảo các ứng dụng không bị ảnh hưởng bởi lượng gas tăng đột biến do hoạt động trên chuỗi khác như hoạt động đúc NFT phổ biến gây ra. Quan điểm này đúng một phần nhưng phần lớn là sai.

Đây là một vấn đề mang tính lịch sử, bắt nguồn từ bản chất đơn luồng của EVM, không phải vì DA và quá trình thực thi không tách rời nhau. Tất cả các L2 đều trả phí cho L1 và phí L1 có thể tăng bất cứ lúc nào. Trong cơn sốt memecoin hồi đầu năm nay, phí giao dịch trên Arbitrum và Optimism đã nhanh chóng vượt quá 10 USD. Gần đây hơn, phí Optimism cũng tăng vọt sau khi Worldcoin ra mắt.

Giải pháp duy nhất để giải quyết các mức phí cao nhất là: 1) tối đa hóa L1 DA, 2) tinh chỉnh thị trường phí càng nhiều càng tốt:

Nếu tài nguyên của L1 bị hạn chế, mức sử dụng tăng đột biến ở các L2 riêng lẻ sẽ được chuyển sang L1, điều này sẽ khiến tất cả các L2 khác phải chịu chi phí cao hơn. Do đó, AppChain/Rollup không thể tránh khỏi sự tăng đột biến của Gas.

Sự cùng tồn tại của nhiều EVM L2 chỉ là một cách thô thiển để cố gắng bản địa hóa thị trường phí. Nó tốt hơn là đưa thị trường phí vào một EVM L1 duy nhất, nhưng không giải quyết được vấn đề cốt lõi. Khi bạn nhận ra rằng giải pháp làthị trường phí nội địa hóa, điểm cuối hợp lý là thị trường phí theo từng tiểu bang (chứ không phải là thị trường phí theo L2).

Các chuỗi khác đã đi đến kết luận này. Solana và Aptos tự nhiên địa phương hóa thị trường phí. Điều này đòi hỏi nhiều năm làm việc kỹ thuật chuyên sâu cho các môi trường thực thi tương ứng. Hầu hết những người ủng hộ mô-đun đều đánh giá thấp tầm quan trọng và khó khăn của việc xây dựng kỹ thuật thị trường phí địa phương.

Bằng cách tung ra nhiều chuỗi, các nhà phát triển không đạt được hiệu suất thực sự. Khi có các ứng dụng thúc đẩy khối lượng giao dịch, chi phí của tất cả các chuỗi L2 sẽ bị ảnh hưởng.

tính linh hoạt được đánh giá cao

Những người ủng hộ chuỗi mô-đun cho rằng kiến ​​trúc mô-đun linh hoạt hơn. Tuyên bố này rõ ràng là đúng, nhưng nó có thực sự quan trọng?

Trong sáu năm, tôi đã cố gắng tìm kiếm các nhà phát triển ứng dụng mà L1 chung không mang lại sự linh hoạt có ý nghĩa. Nhưng cho đến nay, ngoài ba trường hợp sử dụng rất cụ thể, không ai có thể nói rõ lý do tại sao tính linh hoạt lại quan trọng và nó trực tiếp hỗ trợ việc mở rộng quy mô như thế nào. Ba trường hợp sử dụng cụ thể mà tôi thấy tính linh hoạt quan trọng là:

Các ứng dụng tận dụng trạng thái “nóng”. Trạng thái nóng là trạng thái cần thiết để điều phối một số tập hợp hoạt động trong thời gian thực, nhưng nó sẽ chỉ được đưa vào chuỗi tạm thời và sẽ không tồn tại mãi mãi. Một số ví dụ về trạng thái nhiệt:

• Các lệnh giới hạn trong DEX như dYdX và Sei (nhiều lệnh giới hạn cuối cùng bị hủy).

• Điều phối và xác định luồng đơn hàng theo thời gian thực trong dFlow (dFlow là giao thức hỗ trợ thị trường luồng đơn hàng phi tập trung giữa các nhà tạo lập thị trường và ví).

• Một oracle như Pyth, là một oracle có độ trễ thấp. Python chạy như một chuỗi SVM độc lập. Python tạo ra nhiều dữ liệu đến mức nhóm Python cốt lõi quyết định tốt nhất nên gửi thông tin cập nhật giá tần suất cao tới một chuỗi độc lập, sau đó sử dụng Wormhole để kết nối giá với các chuỗi khác nếu cần.

Sửa đổi chuỗi đồng thuận. Các ví dụ điển hình nhất là Osmosis (trong đó tất cả các giao dịch được mã hóa trước khi gửi đến người xác thực) và Thorchain (trong đó các giao dịch trong một khối được ưu tiên dựa trên phí phải trả).

Bằng cách nào đó, cơ sở hạ tầng của Lược đồ chữ ký ngưỡng (TSS) cần được khai thác. Một số ví dụ về điều này là Sommelier, Thorchain, Osmosis, Wormhole và Web3 Auth.

Ngoại trừ Pyth và Wormhole, tất cả các ví dụ được liệt kê ở trên đều được xây dựng bằng SDK Cosmos và chạy dưới dạng chuỗi độc lập. Điều này nói lên nhiều điều về khả năng ứng dụng và khả năng mở rộng của Cosmos SDK cho cả ba trường hợp sử dụng: trạng thái nóng, sửa đổi đồng thuận và hệ thống Sơ đồ chữ ký ngưỡng (TSS).

Tuy nhiên, hầu hết các hạng mục trong ba trường hợp sử dụng trên không phải là ứng dụng mà là cơ sở hạ tầng.

Python và dFlow không phải là ứng dụng, chúng là cơ sở hạ tầng. Sommelier, Wormhole, Sei và Web3 Auth không phải là ứng dụng, chúng là cơ sở hạ tầng. Trong số đó, chỉ có một loại ứng dụng cụ thể hướng tới người dùng: DEX (dYdX, Osmosis, Thorchain).

Trong sáu năm, tôi đã hỏi những người đề xuất Cosmos và Polkadot về các trường hợp sử dụng nhờ tính linh hoạt mà chúng mang lại. Tôi nghĩ có đủ dữ liệu để đưa ra một số suy luận:

Đầu tiên, các ví dụ về cơ sở hạ tầng không nên tồn tại dưới dạng Bản tổng hợp vì chúng tạo ra quá nhiều dữ liệu có giá trị thấp (chẳng hạn như trạng thái nóng và toàn bộ vấn đề của trạng thái nóng là dữ liệu không được đưa trở lại L1) hoặc vì chúng làm điều gì đó được cố ý gắn với chức năng liên quan đến cập nhật trạng thái, sổ cái tài sản (ví dụ: tất cả các trường hợp sử dụng TSS).

Thứ hai, loại ứng dụng duy nhất mà tôi thấy sẽ được hưởng lợi từ việc thay đổi thiết kế của hệ thống cốt lõi là DEX. Bởi vì DEX tràn ngập MEV và Universal Chain không thể sánh được với độ trễ của CEX. Sự đồng thuận là nền tảng của chất lượng thực hiện giao dịch và MEV, vì vậy những thay đổi dựa trên sự đồng thuận đương nhiên sẽ mang lại nhiều cơ hội đổi mới cho DEX. Tuy nhiên, như đã đề cập trước đó trong bài viết này, đầu vào chính của DEX giao ngay là tài sản đang được giao dịch. DEX cạnh tranh để giành tài sản và do đó cạnh tranh với các nhà phát hành tài sản. Trong khuôn khổ này, chuỗi DEX độc lập khó có thể thành công, vì sự cân nhắc chính của nhà phát hành tài sản khi phát hành tài sản không phải là MEV liên quan đến DEX mà là chức năng hợp đồng thông minh chung và việc kết hợp chức năng này vào các ứng dụng tương ứng của nhà phát triển.

Tuy nhiên, DEX phái sinh không cần phải cạnh tranh để giành quyền phát hành tài sản. Họ chủ yếu dựa vào tài sản thế chấp như USDC và máy oracle để cung cấp giá và về cơ bản phải khóa tài sản của người dùng để thế chấp các vị thế phái sinh. Vì vậy, theo nghĩa của chuỗi DEX độc lập, rất có thể chúng có thể áp dụng cho các DEX tập trung vào phái sinh như dYdX và Sei.

Hãy xem xét các ứng dụng L1 tích hợp chung tồn tại ngày nay, bao gồm: trò chơi, hệ thống DeSoc (như Farcaster và Lens), giao thức DePIN (như Helium, Hivemapper, Render Network, DIMO và Daylight), Âm thanh, trao đổi NFT, v.v. . Không ai trong số này được hưởng lợi đặc biệt từ tính linh hoạt có được bằng cách sửa đổi sự đồng thuận và sổ cái tài sản tương ứng của họ có một bộ yêu cầu khá đơn giản, rõ ràng và phổ biến: phí thấp, độ trễ thấp, quyền truy cập vào các DEX giao ngay, quyền truy cập vào stablecoin và quyền truy cập vào các kênh fiat, ví dụ CEX.

Tôi tin rằng hiện tại chúng tôi có đủ dữ liệu để nói ở một mức độ nào đó rằng phần lớn các ứng dụng hướng tới người dùng đều có các yêu cầu chung giống như những yêu cầu được liệt kê trong đoạn trước. Mặc dù một số ứng dụng có thể tối ưu hóa các biến khác ở lề bằng các tính năng tùy chỉnh trong ngăn xếp, nhưng sự đánh đổi từ các tùy chỉnh này thường không đáng giá (nhiều cầu nối hơn, ít hỗ trợ ví hơn, ít hỗ trợ chương trình lập chỉ mục/truy vấn hơn, giảm kênh fiat, v.v.). ).

Triển khai sổ cái tài sản mới là một cách để đạt được tính linh hoạt, nhưng nó hiếm khi tăng thêm giá trị và hầu như luôn tạo ra sự phức tạp về mặt kỹ thuật và xã hội mà mang lại rất ít lợi ích cuối cùng cho các nhà phát triển ứng dụng.

DA mở rộng không yêu cầu thế chấp lại

Bạn cũng sẽ nghe những người đề xuất mô-đun nói về việc tái giả định trong bối cảnh mở rộng quy mô. Đây là lập luận mang tính suy đoán nhất được đưa ra bởi những người ủng hộ chuỗi mô-đun, nhưng cũng đáng để thảo luận.

Nó đại khái tuyên bố rằng do tái cấu trúc (ví dụ: thông qua các hệ thống như EigenLayer), toàn bộ hệ sinh thái tiền điện tử có thể tái cấu trúc ETH với số lần không giới hạn, cho phép số lượng lớp DA không giới hạn (ví dụ: EigenDA) và các lớp thực thi. Do đó, trong khi đảm bảo giá trị gia tăng của ETH, khả năng mở rộng được giải quyết từ mọi khía cạnh.

Bất chấp sự không chắc chắn to lớn giữa hiện trạng và tương lai về mặt lý thuyết, chúng tôi chấp nhận rằng tất cả các giả định phân tầng đều hoạt động như đã quảng cáo.

DA hiện tại của Ethereum là khoảng 83 KB/s. Với sự ra mắt của EIP-4844 vào cuối năm nay, tốc độ đó có thể tăng gấp đôi lên khoảng 166 KB/s. EigenDA có thể thêm 10 MB/s bổ sung, nhưng yêu cầu một bộ giả định bảo mật khác (không phải tất cả ETH sẽ được giả định lại thành EigenDA).

Để so sánh, Solana hiện cung cấp DA khoảng 125 MB/s (32.000 mảnh mỗi khối, 1.280 byte mỗi mảnh, 2,5 khối mỗi giây). Solana hiệu quả hơn nhiều so với Ethereum và EigenDA. Ngoài ra, theođịnh luật Nelson, DA của Solana tăng dần theo thời gian.

Có nhiều cách để mở rộng quy mô DA ​​thông qua tái thế chấp và mô-đun hóa, nhưng ngày nay những cơ chế này đơn giản là không cần thiết và gây ra sự phức tạp rõ ràng về mặt kỹ thuật và xã hội.

Được xây dựng cho các nhà phát triển ứng dụng

Sau nhiều năm suy nghĩ, tôi đi đến kết luận rằng bản thân tính mô-đun không nên là một mục tiêu.

Một blockchain phải phục vụ khách hàng của mình (tức là các nhà phát triển ứng dụng), do đó, blockchain phải trừu tượng hóa độ phức tạp ở cấp độ cơ sở hạ tầng để các nhà phát triển có thể tập trung vào việc xây dựng các ứng dụng đẳng cấp thế giới.

Tính mô-đun là tuyệt vời. Nhưng chìa khóa để xây dựng các công nghệ thành công là tìm ra phần nào của hệ thống cần được tích hợp và phần nào để lại cho những phần khác. Như hiện tại, các chuỗi tích hợp DA và thực thi vốn đã mang lại trải nghiệm đơn giản hơn cho nhà phát triển và người dùng cuối, đồng thời cuối cùng sẽ cung cấp nền tảng tốt hơn cho các ứng dụng tốt nhất.