Suy nghĩ của đối tác Multicoin: Vì sao nói các blockchain mô-đun bị thổi phồng quá mức?
Tuyển chọn TechFlowTuyển chọn TechFlow
Suy nghĩ của đối tác Multicoin: Vì sao nói các blockchain mô-đun bị thổi phồng quá mức?
Module hóa rất tuyệt, nhưng chìa khóa để xây dựng công nghệ chiến thắng là phải xác định được phần nào trong stack cần tích hợp và phần nào nên để cho người khác thực hiện.
Chuyên sâu báo cáo Web3Tác giả: Kyle Samani, Đối tác tại Multicoin Capital
Biên dịch: Luffy, Foresight News
Trong hai năm qua, cuộc tranh luận về khả năng mở rộng blockchain đã tập trung vào một chủ đề trung tâm: “tranh luận giữa mô-đun và tích hợp”.
Lưu ý rằng trong các cuộc thảo luận tiền mã hóa, người ta thường nhầm lẫn giữa hệ thống "đơn nhất" và "tích hợp". Cuộc tranh luận kỹ thuật giữa hệ thống tích hợp và hệ thống mô-đun đã kéo dài suốt 40 năm lịch sử. Cuộc đối thoại trong lĩnh vực tiền mã hóa cần được đặt trong cùng góc nhìn này – đây hoàn toàn không phải là một cuộc tranh luận mới mẻ.
Khi xem xét 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 độ phơi bày sự phức tạp của ngăn xếp đến nhà phát triển ứng dụng. Khách hàng của blockchain chính là các nhà phát triển ứng dụng, do đó, quyết định thiết kế cuối cùng cần cân nhắc vị trí của họ.
Hiện nay, mô-đun phần lớn được ca ngợi là cách thức chính để mở rộng blockchain. Trong bài viết này, tôi sẽ chất vấn giả định này từ những nguyên lý cơ bản, vạch trần những huyền thoại văn hóa và chi phí ẩn đằng sau các hệ thống mô-đun, đồng thời chia sẻ những kết luận tôi rút ra sau sáu năm suy ngẫm về cuộc tranh luận này.
Hệ thống mô-đun làm tăng độ phức tạp trong phát triển
Cho đến nay, chi phí ẩn lớn nhất của hệ thống mô-đun là việc gia tăng độ phức tạp trong quy trình phát triển.
Các hệ thống mô-đun làm tăng đáng kể độ phức tạp mà nhà phát triển ứng dụng phải quản lý, cả trong bối cảnh ứng dụng riêng (phức tạp kỹ thuật) lẫn khi 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 mã hóa, về mặt lý thuyết blockchain mô-đun cho phép chuyên môn hóa cao hơn, nhưng đổi lại là tạo ra những lớp phức tạp mới. Những lớp phức tạp này (về bản chất vừa kỹ thuật vừa xã hội) đang được chuyển giao cho các nhà phát triển ứng dụ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. Cho đến nay, dường như đây là khung mô-đun phổ biến nhất. OP Stack buộc các nhà phát triển phải chọn giữa việc tuân theo Luật Chuỗi (kéo theo nhiều phức tạp xã hội), hoặc fork và tự quản lý độc lập. Cả hai lựa chọn đều gây ra hậu quả phức tạp nghiêm trọng 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ừ các bên tham gia hệ sinh thái khác (sàn giao dịch tập trung, cổng fiat,...) vốn phải tốn chi phí để đáp ứng tiêu chuẩn công nghệ mới? Nếu bạn chọn tuân theo Luật Chuỗi, thì hôm nay và ngày mai, bạn sẽ bị áp đặt những quy tắc và ràng buộc nào?
Nguồn: Mô hình OSI
Các 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. Hệ điều hành hiện đại xử lý các tầng 2–6 trong sơ đồ trên. Đây là ví dụ điển hình về việc tích hợp các thành phần mô-đun nhằm quản lý độ phức tạp của ngăn xếp mà không phơi bày ra cho nhà phát triển ứng dụng. Nhà phát triển ứng dụng không muốn xử lý bất kỳ thứ gì dưới tầng 7 – đó chính xác là lý do tồn tại của hệ điều hành: hệ điều hành quản lý sự phức tạp ở các tầng dưới để nhà phát triển ứng dụng có thể tập trung vào tầng 7. Vì vậy, mô-đun hóa bản thân nó không nên là mục tiêu, mà chỉ là phương tiện để đạt được mục đích.
Mọi hệ thống phần mềm lớn hiện nay – backend đám mây, hệ điều hành, động cơ cơ sở dữ liệu, động cơ trò chơi, v.v. – đều cực kỳ tích hợp, đồng thời bao gồm nhiều hệ thống con mô-đun. Các hệ thống phần mềm có xu hướng tích hợp cao để tối đa hóa hiệu suất và giảm thiểu độ phức tạp trong phát triển. Blockchain cũng không ngoại lệ.
Nhân tiện nói thêm, Ethereum đang giảm bớt sự phức tạp từng xuất hiện trong thời kỳ fork Bitcoin từ 2011–2014. Những người ủng hộ mô-đun thường nhấn mạnh mô hình Open Systems Interconnection (OSI), cho rằng tính sẵn có dữ liệu (DA) và thực thi nên tách rời; tuy nhiên, lập luận này bị hiểu lầm rộng rãi. Hiểu đúng vấn đề hiện tại sẽ dẫn đến kết luận ngược lại: OSI thực chất là minh chứng cho hệ thống tích hợp chứ không phải hệ thống mô-đun.
Chuỗi mô-đun không thể thực thi mã nhanh hơn
Theo định nghĩa, đặc điểm phổ biến của “chuỗi mô-đun” là sự tách biệt giữa tính sẵn có dữ liệu (DA) và thực thi: một nhóm nút chịu trách nhiệm về DA, trong khi một nhóm (hoặc nhiều nhóm) nút khác chịu trách nhiệm về thực thi. Các tập hợp nút này không cần trùng lặp, nhưng có thể trùng.
Trong thực tế, việc tách rời DA và thực thi không làm tăng bản chất hiệu suất của cả hai; thay vào đó, ở đâu đó trên thế giới, phần cứng vẫn phải thực hiện DA, và ở nơi khác, phần cứng vẫn phải thực hiện việc thực thi. Việc tách chức năng này không cải thiện hiệu suất của bất kỳ thành phần nào. Dù tách rời có thể giảm chi phí tính toán, nhưng chỉ có thể thông qua việc tập trung hóa thực thi.
Cần nhấn mạnh lại: dù kiến trúc mô-đun hay tích hợp, thì ở đâu đó vẫn phải có phần cứng thực hiện công việc, và việc tách DA và thực thi sang phần cứng riêng biệt sẽ không bản chất tăng tốc hay nâng tổng dung lượng hệ thống.
Một số người cho rằng mô-đun cho phép nhiều EVM chạy song song dưới dạng Rollup, nhờ đó thực thi có thể mở rộng ngang. Mặc dù điều này đúng về mặt lý thuyết, nhưng thực tế lập luận này nhấn mạnh vào hạn chế của EVM như một bộ xử lý đơn luồng, chứ không phải là tiền đề cốt lõi về tách rời DA và thực thi trong bối cảnh mở rộng tổng thông lượng hệ thống.
Việc mô-đun hóa đơn thuần không thể cải thiện 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 đều 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 đoạn trạng thái riêng biệt này có thể giao tiếp với nhau, mặc dù với độ trễ giao dịch dài hơn và tình huống phức tạp hơn cho cả nhà phát triển lẫn người dùng (thông qua các cầu nối như LayerZero và Wormhole).
Số lượng sổ cái tài sản càng nhiều thì trạng thái toàn cục của tất cả tài khoản càng bị phân mảnh. Điều này thật tệ hại đối với cả các chuỗi lẫn người dùng trải qua nhiều chuỗi. Phân mảnh trạng thái có thể dẫn đến một loạt hậu quả:
-
Thanh khoản giảm, dẫn đến trượt giá giao dịch cao hơn;
-
Tổng mức tiêu thụ Gas tăng lên (giao dịch chéo 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 trùng lặp giữa các sổ cái tài sản (do đó làm giảm tổng thông lượng hệ thống): Khi giá ETH-USDC thay đổi trên Binance hoặc Coinbase, cơ hội arbitrage sẽ xuất hiện trên mọi cặp ETH-USDC ở 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 lần giá ETH-USDC thay đổi, sẽ có hơn 10 giao dịch diễn ra trên các sổ cái tài sản khác nhau). Việc duy trì giá cả nhất quán trong 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 thêm nhiều sổ cái tài sản sẽ rõ ràng làm tăng chi phí ở tất cả các chiều kích này, đặc biệt là những chi phí 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/Rollup, họ tự nhiên tạo ra phân mảnh trạng thái – điều này rất xấu đối với DeFi, cả về phía nhà phát triển (cầu nối, ví, độ trễ, MEV chéo chuỗi,...) lẫn người dùng (trượt giá, độ trễ thanh toán).
Đ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à giao dịch trong một máy trạng thái đơn nhất. Số lượng sổ cái tài sản càng nhiều, nhà phát triển ứng dụng càng phải quản lý nhiều sự phức tạp, và người dùng càng phải gánh thêm chi phí.
Rollup ứng dụng không tạo ra cơ hội kiếm tiền mới cho nhà phát triển
Những người ủng hộ chuỗi ứng dụng/Rollup cho rằng động lực sẽ thúc đẩy các nhà phát triển xây dựng Rollup thay vì xây dựng trên L1 hoặc L2, để ứng dụng có thể tự thu giữ giá trị MEV. Tuy nhiên, suy nghĩ này là sai lầm, bởi vì vận hành Rollup ứng dụng không phải là cách duy nhất – và trong hầu hết trường hợp cũng không phải là cách tốt nhất – để thu giữ MEV về token ở tầng ứng dụng. Token ở tầng ứ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 giữ lại MEV về chính token của mình. Hãy xem xét vài ví dụ:
-
Thanh lý: Nếu DAO Compound hoặc Aave muốn thu giữ một phần MEV chảy về các bot thanh lý, họ chỉ cần cập nhật hợp đồng tương ứng để một phần phí hiện tại chảy về bot thanh lý sẽ được chuyển về DAO của chính họ – không cần chuỗi/Rollup mới.
-
Oracles: Các token oracle có thể thu giữ MEV bằng cách cung cấp dịch vụ back running. Ngoài cập nhật giá, oracle còn có thể đóng gói bất kỳ giao dịch trên chuỗi nào đảm bảo được thực thi ngay sau khi cập nhật giá. Do đó, oracle có thể thu giữ MEV bằng cách cung cấp dịch vụ back running cho các searcher, builder khối, v.v.
-
Đúc NFT: Việc đúc NFT tràn ngập các bot đầu cơ. Tình trạng này có thể dễ dàng giảm nhẹ bằng cách mã hóa lại việc phân phối lợi nhuận giảm dần. Ví dụ, nếu ai đó cố gắng bán lại NFT trong vòng hai tuần sau khi đúc, 100% doanh thu sẽ quay trở lại nhà phát hành hoặc DAO. Theo thời gian, tỷ lệ phần trăm này có thể thay đổi.
Không có câu trả lời chung cho việc thu giữ MEV vào token ở tầng ứ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 giữ lại MEV vào token của mình trên chuỗi phổ quát. Việc ra mắt một chuỗi hoàn toàn mới là không cần thiết, chỉ làm tăng thêm độ phức tạp kỹ thuật và xã hội cho nhà phát triển, đồng thời gây thêm rắc rối về ví và thanh khoản cho người dùng.
Rollup ứng dụng không giải quyết được tắc nghẽn giữa các ứng dụng
Nhiều người cho rằng chuỗi ứng dụng/Rollup đảm bảo ứng dụng sẽ không bị ảnh hưởng bởi các đỉnh Gas do hoạt động trên các chuỗi khác gây ra (ví dụ như việc đúc NFT phổ biến). Quan điểm này một phần đúng, nhưng phần lớn là sai.
Đây là vấn đề lịch sử, nguyên nhân gốc rễ nằm ở bản chất đơn luồng của EVM, chứ không phải vì DA và thực thi chưa được tách rời. Tất cả các L2 đều phải 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, phí giao dịch trên Arbitrum và Optimism từng vượt quá 10 USD. Gần đây, phí trên Optimism cũng tăng vọt sau khi Worldcoin ra mắt.
Giải pháp duy nhất cho các đỉnh phí là: 1) Tối đa hóa DA L1, 2) Phân mảnh thị trường phí càng chi tiết càng tốt:
Nếu tài nguyên L1 bị giới hạn, các đỉnh sử dụng trong từng L2 riêng biệt sẽ truyền ngược lên L1, từ đó làm tăng chi phí cho tất cả các L2 khác. Do đó, chuỗi ứng dụng/Rollup không thể tránh khỏi các đỉnh Gas.
Sự tồn tại đồng thời của nhiều L2 EVM chỉ là một cách thô sơ để cố gắng địa phương hóa thị trường phí. Nó tốt hơn việc đặt thị trường phí vào một L1 EVM đơn lẻ, nhưng không giải quyết được vấn đề cốt lõi. Khi bạn nhận ra giải pháp là thị trường phí địa phương hóa, thì điểm kết luận logic là thị trường phí theo từng trạng thái (thay vì theo từng 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 kỹ thuật dày công dành riêng cho môi trường thực thi tương ứng. Phần lớn những người ủng hộ mô-đun đánh giá thấp tầm quan trọng và độ khó kỹ thuật của việc xây dựng thị trường phí địa phương.
Thị trường phí địa phương hóa
Việc ra mắt nhiều chuỗi không mang lại lợi ích thực sự về hiệu suất cho nhà phát triển. Khi có ứng dụng làm tăng khối lượng giao dịch, chi phí của tất cả các chuỗi L2 đều bị ảnh hưởng.
Tính linh hoạt bị thổi phồng quá mức
Những người ủng hộ chuỗi mô-đun cho rằng kiến trúc mô-đun linh hoạt hơn. Câu nói này rõ ràng đúng, nhưng liệu nó thực sự quan trọng?
Trong sáu năm qua, tôi đã cố gắng tìm kiếm các nhà phát triển ứng dụng cần tính linh hoạt mà L1 phổ quát không thể cung cấp. Nhưng cho đến nay, ngoài ba trường hợp cụ thể, chưa ai có thể rõ ràng lý giải tại sao tính linh hoạt lại quan trọng, hay nó giúp mở rộng trực tiếp như thế nào. Tôi thấy tính linh hoạt quan trọng ở ba trường hợp cụ thể sau:
Ứ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 để phối hợp thời gian thực một tập hợp thao tác nhất định, nhưng chỉ tạm thời được lưu lên chuỗi và không tồn tại mãi mãi. Một vài ví dụ về trạng thái nóng:
-
Lệnh giới hạn trong DEX, ví dụ như dYdX và Sei (rất nhiều lệnh giới hạn cuối cùng bị hủy bỏ).
-
dFlow phối hợp và nhận diện dòng lệnh thời gian thực (dFlow là giao thức tạo thị trường dòng lệnh phi tập trung giữa các market maker và ví).
-
Oracle như Pyth – một oracle độ trễ thấp. Pyth chạy như một chuỗi SVM độc lập. Pyth tạo ra quá nhiều dữ liệu đến mức đội ngũ cốt lõi quyết định gửi các cập nhật giá tần suất cao tới một chuỗi riêng, rồi sau đó dùng Wormhole để cầu nối giá tới các chuỗi khác khi cần.
Các chuỗi sửa đổi cơ chế đồng thuận. Ví dụ điển hình nhất là Osmosis (tất cả giao dịch được mã hóa trước khi gửi đến validator), và Thorchain (sắp xếp ưu tiên giao dịch trong khối dựa trên phí trả).
Cơ sở hạ tầng cần tận dụng theo cách nào đó sơ đồ chữ ký ngưỡng (TSS). Một vài ví dụ ở đây là Sommelier, Thorchain, Osmosis, Wormhole và Web3Auth.
Ngoại trừ Pyth và Wormhole, tất cả các ví dụ liệt kê trên đều được xây dựng bằng Cosmos SDK và chạy như các chuỗi độc lập. Điều này chứng tỏ rõ ràng tính phù hợp và khả năng mở rộng của Cosmos SDK đối với cả ba trường hợp: trạng thái nóng, thay đổi đồng thuận và hệ thống TSS.
Tuy nhiên, phần lớn các dự án trong ba trường hợp trên không phải là ứng dụng – chúng là cơ sở hạ tầng.
Pyth 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ố đó, loại ứng dụng duy nhất hướng đến người dùng là một dạng đặc biệt: DEX (dYdX, Osmosis, Thorchain).
Trong sáu năm qua, tôi đã luôn hỏi những người ủng hộ Cosmos và Polkadot về các trường hợp sử dụng mà tính linh hoạt họ cung cấp mang lại. Tôi cho rằng đã có đủ dữ liệu để đưa ra một vài suy luận:
Thứ nhất, các ví dụ về cơ sở hạ tầng không nên tồn tại dưới dạng Rollup, vì chúng hoặc tạo ra quá nhiều dữ liệu giá trị thấp (ví dụ như trạng thái nóng, vốn có ý nghĩa là dữ liệu không được gửi lại L1), hoặc vì chúng thực hiện một số chức năng cố ý liên quan đến cập nhật trạng thái trên sổ cái tài sản (ví dụ: mọi trường hợp dùng TSS).
Thứ hai, loại ứng dụng duy nhất tôi từng thấy có 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ổ quát không thể bắt kịp độ trễ của CEX. Đồng thuận là nền tảng cho chất lượng thực thi giao dịch và MEV, do đó thay đổi đồng thuận tự nhiên 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, đầu vào chính của DEX giao ngay là tài sản đang được giao dịch. DEX cạnh tranh về tài sản, từ đó cạnh tranh về nhà phát hành tài sản. Trong khuôn khổ này, các chuỗi DEX độc lập khó có thể thành công, vì khi phát hành tài sản, nhà phát hành không ưu tiên MEV liên quan đến DEX, mà là chức năng hợp đồng thông minh phổ quát và việc tích hợp chức năng đó vào ứng dụng của riêng họ.
Tuy nhiên, DEX phái sinh không cần cạnh tranh nhà phát hành tài sản; chúng chủ yếu phụ thuộc vào tài sản ký quỹ như USDC và dữ liệu giá từ oracle, đồng thời về bản chất phải khóa tài sản người dùng để thế chấp vị thế phái sinh. Do đó, nếu nói về ý nghĩa của chuỗi DEX độc lập, chúng có nhiều khả năng phù hợp với 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 phổ quát hiện tại: game, hệ thống DeSoc (ví dụ như Farcaster và Lens), các giao thức DePIN (như Helium, Hivemapper, Render Network, DIMO và Daylight), Sound, sàn giao dịch NFT, v.v. Không có ứng dụng nào trong số này đặc biệt hưởng lợi từ tính linh hoạt do thay đổi đồng thuận; sổ cái tài sản tương ứng của chúng đều có một tập hợp yêu cầu khá đơn giản, rõ ràng và chung: phí thấp, độ trễ thấp, truy cập DEX giao ngay, truy cập stablecoin và truy cập kênh fiat như sàn giao dịch tập trung.
Tôi tin rằng hiện tại chúng ta đã có đủ dữ liệu để khẳng định, phần lớn các ứng dụng hướng người dùng đều có những yêu cầu phổ quát giống như những gì liệt kê ở đoạn trước. Mặc dù một số ứng dụng có thể tối ưu hóa một vài biến số khác ở biên bằng các chức năng tùy chỉnh trong ngăn xếp, nhưng sự đánh đổi do tùy chỉnh mang lại thường không đáng (nhiều cầu nối hơn, ít hỗ trợ ví hơn, ít hỗ trợ indexer/trình truy vấn hơn, giảm kênh fiat, v.v.).
Việc ra mắt sổ cái tài sản mới là một cách để đạt được tính linh hoạt, nhưng hiếm khi tạo thêm giá trị, và gần như luôn mang lại sự phức tạp kỹ thuật và xã hội, trong khi lợi ích cuối cùng cho nhà phát triển ứng dụng là rất nhỏ.
Mở rộng DA không cần tái thế chấp
Bạn cũng sẽ nghe những người ủng hộ mô-đun nói về việc tái thế chấp trong bối cảnh mở rộng. Đây là lập luận mang tính suy đoán nhất từ những người ủng hộ chuỗi mô-đun, nhưng đáng để bàn luận.
Lập luận này đại khái cho rằng, nhờ tái thế chấp (ví dụ qua các hệ thống như EigenLayer), toàn bộ hệ sinh thái tiền mã hóa có thể tái thế chấp ETH vô hạn lần, từ đó trao quyền cho vô số tầng DA (ví dụ như EigenDA) và tầng thực thi. Như vậy, trong khi đảm bảo giá trị ETH tăng trưởng, mọi khía cạnh về khả năng mở rộng đều được giải quyết.
Mặc dù có khoảng cách lớn giữa thực tế hiện tại và viễn cảnh lý thuyết, chúng ta vẫn nên coi các giả định phân tầng đều hoạt động như quảng cáo.
Hiện tại, DA của Ethereum khoảng 83 KB/s. Với việc ra mắt EIP-4844 vào cuối năm nay, tốc độ này sẽ tăng gấp đôi lên khoảng 166 KB/s. EigenDA có thể bổ sung thêm 10 MB/s, nhưng cần một tập hợp giả định an ninh khác (không phải tất cả ETH đều tái thế chấp vào EigenDA).
So sánh, Solana hiện cung cấp DA khoảng 125 MB/s (mỗi khối 32.000 shred, mỗi shred 1.280 byte, 2,5 khối mỗi giây). Solana hiệu quả hơn nhiều so với Ethereum và EigenDA. Hơn nữa, theo Định luật Nielsen, DA của Solana sẽ mở rộng theo thời gian.
Có nhiều cách để mở rộng DA thông qua tái thế chấp và mô-đun, nhưng những cơ chế này hiện tại hoàn toàn không cần thiết và mang lại rõ ràng sự phức tạp kỹ thuật và xã hội.
Xây dựng vì nhà phát triển ứng dụng
Sau nhiều năm suy ngẫm, tôi đi đến kết luận rằng mô-đun hóa bản thân nó không nên là 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 sự phức tạp ở cấp độ cơ sở hạ tầng, để nhà phát triển có thể tập trung xây dựng các ứng dụng đẳng cấp thế giới.
Mô-đun hóa rất tuyệt. Nhưng chìa khóa để xây dựng công nghệ chiến thắng là xác định phần nào của ngăn xếp cần được tích hợp, và phần nào nên để cho người khác lo. Hiện tại, các chuỗi tích hợp DA và thực thi bản chất cung cấp trải nghiệm đơn giản hơn cho người dùng cuối và nhà phát triển, và cuối cùng sẽ tạo nền tảng tốt hơn cho các ứng dụng hàng đầu.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
Multicoin Capital
