Kyle Samani, đối tác tại Multicoin Capital, đã giải thích chi tiết 7 lý do khiến blockchain mô-đun được định giá quá cao.
Văn bản gốc: Chi phí tiềm ẩn của hệ thống mô-đun
Tác giả: Kyle Samani , Đối tác tại Multicoin Capital
Biên soạn bởi: Luffy, Tin tức tầm nhìn xa
Ảnh bìa: Ảnh của Nathan Watson trên Bapt
Trong hai năm qua, cuộc tranh luận mở rộng blockchain đã tập trung vào chủ đề trọng tâm là “cuộc tranh luận giữa mô-đun và tích hợp”.
Lưu ý rằng các cuộc thảo luận về crypto thường kết hợp các hệ thống "đơn" 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ài lịch sử 40 năm . Cuộc trò chuyện này trong không gian crypto sẽ được đóng khung qua cùng một lăng kính với lịch sử và đây không phải là một cuộc tranh luận mới.
Khi xem xét mô-đun so với tích hợp, quyết định thiết kế quan trọng nhất blockchain có thể đưa ra là mức độ phức tạp của ngăn xếp được bộc lộ đố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 phải tính đến quan điểm của họ.
Ngày nay, mô-đun phần lớn được ca ngợi là cách chính để mở rộng blockchain . Trong bài viết này, tôi sẽ thách thức giả định này từ những nguyên tắc đầu tiên, khám phá 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ẻ những kết luận mà tôi rút ra 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 crypto , về mặt lý thuyết, blockchain 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 lựa chọn giữa việc áp dụng Luật Chuỗi (mang lại nhiều sự phức tạp về mặt xã hội) hoặc fork và quản lý chúng một cách riêng biệt. Cả hai tùy chọn đều tạo ra sự phức tạp đáng kể ở khâu hạ nguồn cho người xây dựng. Nếu bạn chọn fork, liệu bạn có nhận được hỗ trợ kỹ thuật từ những người tham gia hệ sinh thái khác (CEX, fiat on-ramp, 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?
Hệ điều hành (OS) hiện đại là những hệ thống lớn, phức tạp 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ề tích hợp các thành phần mô-đun để quản lý độ 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: 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 đó, mô-đun tự nó không phải là một mục tiêu mà là một 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 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 blockchain.
Nhân tiện, Ethereum đang giảm bớt sự phức tạp xuất hiện trong kỷ nguyên fork Bitcoin 2011-2014. Những người ủng hộ mô-đun thường nhấn mạnh mô hình Kết nối hệ thống mở (OSI), cho 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: lập luận rằng OSI là tích hợp chứ không phải là một hệ thống mô-đun .
Chuỗi mô-đun đun không thể thực thi mã nhanh hơn
Theo thiết kế, định nghĩa chung về " Chuỗi mô-đun đ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 tập hợp nút chịu trách nhiệm về DA, trong khi một tập hợp (hoặc các bộ) nút khác chịu trách nhiệm thực thi. Các 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 hiện DA và một số phần cứng ở đâu đó phải triển khai thực thi. Việc tách biệt các chức năng này không cải thiện hiệu suất trong đó. 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 bằng cách tập trung thực thi.
Xin nhắc lại: Bất kể kiến trúc mô-đun-đun hay tích hợp, một số phần cứng ở đâu đó phải hoàn thành 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 công suất tổng thể của hệ thống.
Một số người cho rằng 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 mở rộng 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 như một bộ xử lý đơn luồng hơn là tiền đề cơ bản của việc tách DA và thực thi trong bối cảnh mở rộng thông lượng toàn hệ thống.
Chỉ riêng mô-đun không cải thiện được thông lượng.
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ù trì hoãn giao dịch lâu hơn và phức tạp hơn đối với nhà phát triển và người dùng (thông qua cầu nối xuyên chuỗi như LayerZero và Wormhole).
Càng có nhiều sổ cái tài sản thì 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 là khủng khiếp đối với Chuỗi và người dùng trên nhiều Chuỗi. Sự phân mảnh trạng thái có thể mang lại sê-ri hậu quả:
- Tính 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 trên các sổ cái tài sản (do đó làm giảm thông lượng tổng thể của hệ thống): Khi giá ETH-USDC di chuyển 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 trên tất cả các sổ cái tài sản (như bạn có thể dễ dàng tưởng tượng Một thế giới nơi mọi thời điểm giá ETH-USDC di chuyển trên Binance hoặc Coinbase, 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à cách 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 ra nhiều sổ cái tài sản hơ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à những khía cạnh 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 đội ngũ khởi chạy Chuỗi ứng dụng/Cuộn, 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 cả 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.) và cho người dùng ( Trượt giá, quyết toán chậm trễ).
Đ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. Sổ cái tài sản càng lớn thì 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í mà người dùng phải chịu càng cao.
Tổng hợp ứng dụng sẽ không tạo cơ hội doanh thu mới cho nhà phát triển
Những người đề xuất Chuỗi/ Rollup cho rằng rằng khích lệ sẽ khiến 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, ý tưởng này có sai sót vì việc chạy bản tổng hợp ứng dụng không phải là phương pháp duy nhất để thu hồi MEV trở lại token lớp ứng dụng và đó không phải là phương pháp tốt nhất trong hầu hết các trường hợp. Token lớp ứng dụng có thể thu hồi MEV thành token của riêng chúng chỉ bằng cách mã hóa logic trong hợp đồng thông minh trên Chuỗi phổ quát. Hãy xem xét một vài ví dụ:
- Thanh lý: Nếu Hợp chất hoặc Aave DAO muốn nắm bắt một phần MEV chảy vào bot thanh lý, họ có thể 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ý được trả cho DAO của chính họ mà không cần cho một Chuỗi mới /Rollup .
- Oracle : 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ũng có thể gộp bất kỳ giao dịch trực Chuỗi tùy ý nào được đảm bảo chạy ngay sau khi cập nhật giá. Do đó, oracle 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.
- Đúc NFT: Đúc NFT có rất nhiều bot bán lại. Điều này có thể dễ dàng được giảm thiểu bằng cách mã hóa việc tái phân bổ lợi nhuận 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 đúc, 100% thu nhập 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 token 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 thu hồi MEV thành token của riêng họ trên Chuỗi phổ quát. Tung ra một Chuỗi hoàn toàn mới đơn giản là không cần thiết và sẽ mang lại sự phức tạp hơn về mặt kỹ thuật và xã hội cho các nhà phát triển, cũng như nhiều mối lo ngại hơn về ví tiền và thanh khoản cho người dùng.
Tổng hợp ứng dụng không thể giải quyết các vấn đề tắc nghẽn giữa các ứng dụng
Nhiều người cho rằng rằng Chuỗi ứng dụng/Cuộn lên đảm bảo rằng các ứng dụng không bị ảnh hưởng bởi lượng gas tăng đột biến do các hoạt động khác trên Chuỗi gây ra, chẳng hạn như đúc NFT phổ biến. Quan điểm này đúng một phần nhưng phần lớn là sai.
Đây là một vấn đề lịch sử và nguyên nhân cốt lõi là do tính chất đơn luồng của EVM chứ không phải do không có sự tách biệt giữa DA và việc thực thi. 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 ĐÔ LA. Gần đây, phí của Optimism cũng tăng vọt sau khi Worldcoin tung ra.
Các giải pháp duy nhất để giải quyết vấn đề phí tăng đột biến 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 cao nhất trong mỗi L2 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 đó, Chuỗi ứng dụng/cuộn lên không tránh khỏi sự tăng đột biến gas .
Sự tồn tại chung của nhiều EVM L2 chỉ là một cách thô thiển để thử nghiệm thị trường phí nội địa hóa. Nó tốt hơn việc đưa thị trường phí vào một EVM L1 duy nhất, nhưng nó 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í địa phương , điểm cuối hợp lý là thị trường phí theo từng tiểu bang (chứ không phải thị trường phí theo L2).
Chuỗi khác đã đi đến kết luận này. Solana và Aptos địa phương hóa thị trường phí một cách tự nhiên. Điều này đòi hỏi công việc kỹ thuật lượng lớn trong nhiều năm đối với hoàn cảnh 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 thiết kế thị trường phí địa phương.
Thị trường phí bản địa hóa, nguồn: Solana
Bằng cách tung ra nhiều Chuỗi, các nhà phát triển không đạt được lợi nhuận suất thực sự. Khi có các ứng dụng thúc đẩy khối lượng giao dịch tăng lên, chi phí của tất cả Chuỗi L2 đều 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 có tính linh hoạt đáng kể mà L1 thông thường không thể cung cấp. 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õ tại sao tính linh hoạt lại quan trọng và nó trực tiếp giúp mở rộng như thế nào. Ba trường hợp sử dụng cụ thể mà tôi thấy tính linh hoạt là 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 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).
- Luồng đơn hàng được điều phối và xác định theo thời gian thực trong dFlow, một giao thức tạo điều kiện cho thị trường luồng đơn hàng phi tập trung giữa nhà tạo lập thị trường và ví.
- Oracle như Pyth, là oracle có độ trễ thấp. Pyth chạy như một Chuỗi SVM độc lập. Pyth tạo ra nhiều dữ liệu đến mức đội ngũ Pyth cốt lõi quyết định tốt nhất là gửi thông tin cập nhật giá tần suất cao đến một Chuỗi độc lập và sau đó sử dụng Wormhole để kết nối giá với 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 crypto 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 sắp xếp dựa trên phí phải trả).
Cần có cơ sở hạ tầng để tận dụng Lược đồ chữ ký ngưỡng (TSS) theo một cách nào đó. Một số ví dụ về điều này là Sommelier, THORChain, Osmosis, Wormhole và Web3Auth.
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à 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 dự án 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à Web3Auth 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 ủng hộ Cosmos và Polkadot về các trường hợp sử dụng nhờ tính linh hoạt mà họ mang lại. Tôi cho rằng có đủ dữ liệu để đưa ra một số suy đoán:
Trước hết, 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 như vậy nội dung nào đó có chủ ý không nhất quán với tài sản trên sổ cái.Chức năng liên quan đến cập nhật trạng thái (ví dụ: tất cả các trường hợp sử dụng TSS).
Thứ hai, ứng dụng duy nhất tôi thấy có thể hưởng lợi từ việc thay đổi thiết kế hệ thống cốt lõi là DEX. Bởi vì DEX tràn ngập MEV và Chuỗi phổ thông không thể sánh được với độ trễ của CEX. Sự đồng thuận là cơ sở cho 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 spot là tài sản đang được giao dịch. DEX cạnh tranh để giành tài sản và do đó là 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ì vấn đề chính mà các nhà phát hành tài sản cân nhắc 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à 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 sẽ áp dụng cho các DEX tập phái sinh như dYdX và Sei .
Hãy xem xét các ứng dụng L1 tích hợp hiện đang tồn tại, 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, sàn giao dịch NFT, v.v. Không ai trong số này đặc biệt được hưởng lợi từ tính linh hoạt do sửa đổi sự đồng thuận mang lại và sổ cái tài sản tương ứng của chúng 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 DEX spot, 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ùng các yêu cầu chung đượ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 đi kèm với 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ợ lập chỉ mục / chương trình truy vấn hơn, giảm tiền tệ hợp pháp kênh, v.v.).
Tung ra 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 nhuận cuối cùng cho các nhà phát triển ứng dụng.
Mở rộng DA không cần thế chấp lại
Bạn cũng sẽ nghe những người ủng hộ mô-đun nói về việc tái giả định trong bối cảnh mở rộng . Đây là lập luận mang tính suy đoán nhất được đưa ra bởi những người đề xuất Chuỗi mô-đun , nhưng nó đáng để thảo luận.
Nó đại khái tuyên bố rằng do việc đặt cược lại (ví dụ: thông qua các hệ thống như EigenLayer), toàn bộ hệ sinh thái crypto có thể đặt cược lại ETH không giới hạn lần, trao quyền cho 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ị ETH được đánh giá cao, 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 rất lớn giữa tình hình hiện tại và tương lai về mặt lý thuyết, chúng tôi cho 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 tung ra của EIP-4844 vào cuối năm nay, tốc độ đó sẽ 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 thế chấp lại cho 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, DA của Solana mở rộng theo thời gian theo Định luật Nelson .
Có nhiều phương pháp để mở rộng DA thông qua việc đặt lại và mô-đun , nhưng những cơ chế này đơn giản là không cần thiết ngày nay và sẽ gây ra sự phức tạp đáng kể 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ĩ về nó, tôi đã đi đến kết luận rằng bản thân mô-đun không nên là một mục tiêu.
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 nên 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.
Mô-Đun là tuyệt vời. Nhưng chìa khóa để xây dựng công nghệ thành công là tìm ra phần nào của hệ thống cần tích hợp và phần nào để lại cho những phần khác. Hiện tại, tích hợp DA và Chuỗi 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.
Tuyên bố miễn trừ trách nhiệm: Là blockchain, các bài viết được xuất bản trên trang này chỉ thể hiện quan điểm cá nhân của tác giả và khách và không liên quan gì đến quan điểm của Web3Caff. Nội dung của bài viết này chỉ nhằm mục đích chia sẻ thông tin và không cấu thành bất kỳ lời khuyên hay đề nghị đầu tư nào. Vui lòng tuân thủ luật pháp và quy định có liên quan của quốc gia hoặc khu vực nơi bạn sinh sống.
