Bài viết này hiểu được điểm nóng mới nổi trong lĩnh vực blockchain “danh sách tổng hợp dành riêng cho ứng dụng”.
Được viết bởi:Phòng thí nghiệm Smrti
Biên soạn: Mô-đun 101
Bản gốc tiếng Anh được xuất bản vào ngày 28 tháng 3 năm 2023. Bài viết này là nửa đầu nội dung.
Bài viết này phân tích toàn diện hệ sinh thái RollApp và so sánh ưu điểm và nhược điểm của bốn giải pháp hiện có.
Dài quá lười đọc:
- Hệ sinh thái tổng hợp dành riêng cho ứng dụng ( RollApp ) hiện tại bao gồm bốn loại : RollApp SDK, Rollup dưới dạng dịch vụ (RaaS), Rollup-SDK dưới dạng dịch vụ và Mạng sắp xếp tự hợp nhất (Mạng tuần tự hợp nhất).
- RollApp SDK giúp các nhà phát triển tạo RollApps được cá nhân hóa. Thông thường, các nhà cung cấp RaaS sử dụng Rollup-SDK để phát triển các dịch vụ, giúp loại bỏ nhu cầu viết bản triển khai RollApp và cung cấp trải nghiệm phát triển tương tự như hợp đồng thông minh.
- Mặc dù RaaS chủ yếu nhắm đến các nhà phát triển hợp đồng thông minh (2C), nhưng cũng cần phải tổng hợp tất cả các SDK khác nhau này cho các nhà phát triển, điều này đã dẫn đến sự xuất hiện của nhà cung cấp dịch vụ 2B Rollup-SDK dưới dạng dịch vụ.
- Các nhà cung cấp sắp xếp hợp nhất chuyên về một số tính năng nhất định của trình sắp xếp trình tự, chẳng hạn như phi tập trung, mở rộng và bảo mật.
- Có bốn loại tổng hợp chính : tổng hợp quyết toán, chủ quyền Rollup, tổng hợp cơ bản và tổng hợp được nhúng. Các SDK RollApp và RaaS khác nhau tập trung vào các loại Bản tổng hợp khác nhau và có sự cân bằng riêng.
- Các dự án RaaS hiện tại cung cấp mức độ tùy chỉnh tương tự . Trọng tâm chính là mức độ triển khai các tính năng này cũng như tốc độ và tính ổn định của quá trình triển khai.
- Giao diện hợp nhất mang lại mô-đun . Mô-Đun mang lại khả năng kết hợp và mở ra tiềm năng của nhiều RollApps khác nhau. Nếu không có giao diện thống nhất, bạn có thể phải đối mặt với một đống khối Lego không tương thích với nhau.
- Trên thị trường, phi tập trung các trình sắp xếp chuỗi có thể yêu cầu sự thỏa hiệp . Thay vào đó, người ta nhấn mạnh nhiều hơn vào việc thực hiện hiệu quả mô hình kinh doanh cũng như khả năng dễ dàng khởi chạy và tùy chỉnh ứng dụng RollApp, ngay cả khi nút ban đầu không phi tập trung.
Các bản tổng hợp dành riêng cho ứng dụng (tức là RollApp) đang trở thành một chủ đề quan trọng trong lĩnh vực blockchain. Mặc dù ý tưởng về “RollApp” vẫn còn non trẻ nhưng chúng tôi đã thấy một số dự án xuất hiện trong không gian này trong năm qua.
Trong phần tổng quan này, chúng tôi muốn nêu bật và so sánh một số giải pháp khác nhau trong lĩnh vực cụ thể này vì chúng có khả năng trở thành những yếu tố quan trọng trong không gian blockchain trong tương lai gần. Trước khi đi sâu vào các giải pháp riêng lẻ này, cần thảo luận về cách chúng tôi đạt được điều này.
Ban đầu, các nhà phát triển chỉ có thể chọn triển khai trên chuỗi Lớp 1 (L1) hiện có (chẳng hạn như Ethereum, v.v.). Mặc dù việc triển khai trên các lớp hiện có cung cấp cho người xây dựng sự đảm bảo bảo mật đầy đủ nhưng họ thiếu các tính năng mở rộng cần thiết để mở rộng quy mô cho người dùng đại chúng.
Để giải quyết vấn đề mở rộng này, chúng tôi bắt đầu thấy ngày càng nhiều Bản tổng hợp xuất hiện thay vì nhiều chuỗi L1 hơn. Rollup cung cấp đủ mở rộng trong khi vẫn duy trì tính bảo mật của chuỗi cơ bản. Mặc dù điều này giải quyết được một số vấn đề mở rộng nhưng vấn đề mà các nhà phát triển hiện gặp phải là khả năng tùy chỉnh.
Mọi dapp được triển khai trên Layer 2 (L2) của Ethereum đều chia sẻ tài nguyên máy tính với tất cả các dapp khác trong danh sách đó, điều này dẫn đến sự cạnh tranh gas gay gắt vì không gian khối hạn chế. Ngoài ra, dapp cũng thiếu khả năng tùy chỉnh vì chúng phải tuân theo các quy tắc tương tự của chuỗi cơ bản mà chúng được triển khai.
Không gian khối hạn chế và thiếu khả năng tùy chỉnh thúc đẩy sự gia tăng của blockchain dành riêng cho ứng dụng (chuỗi ứng dụng) . Loại khung này đã được phổ biến bởi hệ sinh thái Cosmos và sau đó được áp dụng bởi Polygon Superchains, Avalanche Subnets và các loại khác. Tuy nhiên, ngay cả Appchain cũng có những hạn chế riêng, chẳng hạn như phải khởi chạy mạng xác thực của riêng mình và chịu trách nhiệm về bảo mật của chính mình.
Nhưng sẽ tốt hơn nếu các nhà phát triển có thể kết hợp lợi ích bảo mật của việc triển khai trên Rollup với tính linh hoạt của việc có hoàn cảnh chuyên dụng của riêng họ ?
Đây chính xác là những gì Rollup dành riêng cho ứng dụng hoặc "RollApp" cố gắng đạt được. Ý tưởng cơ bản là kết hợp tính bảo mật và tính linh hoạt mượn từ Rollup với tính năng có hoàn cảnh chuyên dụng của riêng bạn.
1. Hệ sinh thái RollApp
Hiện tại, có bốn người chơi chính trong hệ sinh thái RollApp.
SDK RollApps
Đây là một khuôn khổ và bộ công cụ để các nhà phát triển dễ dàng xây dựng các RollApps tùy chỉnh. Tuy nhiên, các nhà phát triển cần hiểu logic blockchain cơ bản để xây dựng các bản tổng hợp dành riêng cho ứng dụng của riêng họ. Các SDK khác nhau tập trung vào các loại tổng hợp khác nhau, với các tùy chọn chống gian lận và hợp lệ khác nhau. Do đó, điều quan trọng là các nhà phát triển phải chọn SDK phù hợp với nhu cầu cụ thể của mình.
Tổng hợp dưới dạng dịch vụ (RaaS)
RaaS đề cập đến nhà cung cấp dịch vụ Rollup. Các nhà cung cấp RaaS thường xây dựng các dịch vụ dựa trên Rollup-SDK (ví dụ: Caldera sử dụng Op Stack). Triển khai tổng hợp không yêu cầu mã. Tất cả nút/cuộc gọi đều do nhà điều hành RaaS xử lý. Đối với các nhà phát triển hợp đồng thông minh, không cần phải hiểu logic khối và trải nghiệm phát triển rất giống với quá trình phát triển hợp đồng thông minh.
Rollup-SDK dưới dạng dịch vụ
Mặc dù RaaS chủ yếu nhắm đến các nhà phát triển hợp đồng thông minh (2C), nhưng cũng cần phải tích hợp nhiều SDK khác nhau, từ đó khai sinh ra nhà cung cấp dịch vụ 2B cho các nhà phát triển, cụ thể là Rollup-SDK dưới dạng dịch vụ. Hiện tại, số lượng dự án tập trung vào lĩnh vực này còn hạn chế. Đội ngũ Đám mô-đun đun đã trình diễn tính năng này vào năm 2022, nhưng trọng tâm hiện tại của họ là xây dựng trình duyệt cho nhiều blockchain mô-đun đun.
mạng sắp xếp thống nhất
Mặc dù mỗi RaaS hoặc SDK cuộn ứng dụng có thể có sắp xếp chuỗi riêng, nhưng vẫn cần có nhà cung cấp sắp xếp chuyên dụng tập trung vào sự đồng thuận và bảo mật của mạng sắp xếp phi tập trung . Mạng sắp xếp được chia sẻ và thống nhất giúp đơn giản hóa việc triển khai tính nguyên tử và khả năng tương tác trên các RollApps khác nhau.
Hình 1. Toàn cảnh sinh thái RollApp
2. Có những loại Rollup nào?
Rollup được thiết kế để mang lại lợi ích mở rộng cho L1. Chúng bao gồm các thành phần khác nhau, bao gồm máy trạm người dùng, máy ảo, sắp xếp thứ tự, hệ thống chứng thực (đặc biệt đối với zk Rollup), một hoặc nhiều nhóm bộ nhớ và hợp đồng cầu nối trên L1.
Mặc dù vẫn còn tranh cãi về việc liệu tổng hợp có nên được xác định bằng hợp đồng cầu nối hay không, chúng tôi có thể phân biệt giữa các tổng hợp "có chủ quyền" và "quyết toán" dựa trên chuỗi/lớp nào đóng vai trò là nguồn sự thật, giống như chúng tôi phân biệt giữa các giao thức cầu nối.
Hình 2. Quyết toán dàn xếp và chủ quyền Rollup
Quyết toán hợp thanh toán đề cập đến các loại dựa vào hợp đồng thông minh trên lớp quyết toán để xác minh bằng chứng và tài sản cầu nối. Hợp đồng thông minh này đóng vai trò là nguồn thông tin chính xác cho chuỗi Rollup. Để bảo vệ hợp đồng thông minh bridge này, nhiều đội ngũ Rollup (chẳng hạn như Arbitrum và Optimism) đã giữ các khóa nâng cấp để sửa các lỗ hổng rõ ràng trên Rollup bất cứ lúc nào. Tuy nhiên, quyền hạn này cũng tạo ra rủi ro thực hiện các thay đổi tùy ý đối với mã mà không được chú ý.
chủ quyền Rollup được Celestia giới thiệu và bản thân Rollup hoạt động giống như một blockchain khối Lớp 1. Bản thân chủ quyền Rollup là nguồn gốc của sự thật, không phải L1. Nút tổng hợp truyền bằng chứng gian lận (tính hợp lệ) thông qua mạng P2P của riêng họ và xác minh chúng cục bộ, trong khi chỉ sử dụng chuỗi cơ bản để lưu trữ các giao dịch đã đặt hàng.
Ngoài ra, cộng đồng chủ quyền Rollup có thể nâng cấp chuỗi thông qua hard fork mà không cần sự cho phép của lớp cơ sở. Điều này có lợi khi một số hành vi nguy hiểm xảy ra và chủ quyền Rollup muốn hoàn tác hành vi đó.
Hình 3. Bản tổng hợp cơ bản và bản tổng hợp được nhúng
Bản tổng hợp cơ bản đề cập đến loại Bản tổng hợp sử dụng nút L1 làm sắp xếp. Thiết kế sắp xếp L1 có thể giúp nó kế thừa tính sống động và phi tập trung của L1, giảm thiểu MEV có hại đến từ sắp xếp tập trung hoặc ngắn hạn. Hiện tại, không có giao thức SDK hoặc RaaS nào sử dụng thiết kế Tổng hợp cơ bản.
Nhúng Rollup có nghĩa là xây dựng khối Rollup trong chính L1. Trên Ethereum, máy trạm thực thi xây dựng một khối chứa Block Header và phần thân khối. Nếu chúng ta gói khối này vào khối Tổng hợp có bằng chứng (tính hợp lệ/lừa đảo), thì những người xác thực khác không cần tính toán lại tất cả các giao dịch, họ chỉ cần tính toán chênh lệch trạng thái và xác minh bằng chứng.
Ý tưởng này rất giống với ý tưởng không trạng thái, trong đó chỉ có một trình tạo chứa trạng thái hoàn chỉnh để tạo ra bằng chứng, sau đó những người khác có thể xác minh trực tiếp mà không cần tải xuống tất cả trạng thái. Hiện tại, Dymension là một cấu trúc Rollup được nhúng, phần thảo luận chi tiết về cấu trúc này sẽ được cung cấp sau trong bài viết này.
3. Tìm hiểu thêm về giải pháp RollApp SDK
3.1 Rollkit và ngăn xếp OP
Vào ngày 21 tháng 2 năm nay, đội ngũ Celestia tung ra Rollkit, một khung Rollup mô-đun đun cho phép các nhà phát triển tự do lựa chọn các chức năng khác nhau để xây dựng các Rollup tùy chỉnh của riêng họ. Điểm khác biệt chính giữa Rollkit và OP Stack là Rollkit hỗ trợ chủ quyền Rollup.
(1) VM do Rollkit cung cấp có thể linh hoạt hơn OP Stack
Lợi ích chính của chủ quyền Rollup không phải là khả năng fork mà là nó cho phép các nhà phát triển không phải viết máy trạm Solidity light cho Rollup.
Điều này có thể khuyến khích sự đổi mới VM linh hoạt hơn vì chúng không bị hạn chế bởi L1 của các bằng chứng gian lận và zk đã được xử lý và quyết toán. Trong nhiều trường hợp, lớp quyết toán cơ bản (chẳng hạn như Ethereum) có thể không xử lý được nó một cách hiệu quả.
OP Stack nhằm mục đích giảm bớt vấn đề này bằng cách xây dựng lớp quyết toán riêng cho tất cả các Superchain. Tuy nhiên, lớp quyết toán vẫn có thể phải tuân theo khả năng quyết toán của Ethereum , đây có thể không phải là nơi hoàn hảo cho các Superchains muốn quyết toán trên các máy ảo khác.
Mỗi mô-đun VM muốn được tích hợp vào OP Stack phải hỗ trợ API Engine, đây là một tập hợp phương pháp được triển khai bởi tất cả máy trạm thực thi Ethereum . API Engine hiện đang được phát triển và không phải tất cả các máy ảo đều hỗ trợ giao diện này. Do đó, vẫn còn rất nhiều việc phải làm để đảm bảo khả năng tương thích với nhiều loại máy ảo hơn.
(2) Việc đóng gói VM và tính không tương thích về ngôn ngữ có thể là những thách thức lớn khi đưa các VM khác vào Rollkit
Tuy nhiên, nếu Rollkit có thể đạt được thiết kế VM linh hoạt hơn thì tại sao lại không có nhiều VM (như SolVM, MoveVM) được đưa vào Rollkit?
Rollkit cung cấp triển khai ứng máy trạm giống ABCI cho Rollup. Điều này có nghĩa là nó xử lý các yêu cầu và chuyển tiếp chúng đến phiên bản ứng dụng cục bộ của nó thông qua Giao diện chuỗi khối ứng dụng (ABCI), được Cosmos SDK giới thiệu ban đầu. Nói cách khác, ABCI cho phép máy trạm và ứng dụng blockchain giao tiếp với nhau ngay cả khi chúng được viết bằng các ngôn ngữ hoàn toàn khác nhau.
Mặt khác, nếu máy trạm trên blockchain muốn giao tiếp với một ứng dụng (ví dụ: VM), thì phương pháp duy nhất là gọi phương pháp ABCI bằng cách gửi yêu cầu.
Do đó, đối với bất kỳ ứng dụng hoặc VM nào, nó phải được gói vào giao diện ABCI để có thể tích hợp vào Rollkit. Đây là một quá trình phức tạp, cho đến nay, VM duy nhất được ABCI bao bọc là EVM (Etheremint).
Ngoài ra, khi phát triển nó cũng sẽ mang đến một số vấn đề khác. ABCI được thiết kế bởi Cosmos-SDK. Do đó, hầu hết các công cụ hiện được sử dụng để xây dựng ứng dụng trên ABCI đều dành riêng cho Golang, điều này gây khó khăn cho những ai muốn đưa ngăn xếp Fuel hoặc Aptos (viết bằng Rust và các ngôn ngữ khác) vào Rollkit.
Phương pháp dễ dàng nhất để Rollkit giao tiếp với các ứng dụng sử dụng ngôn ngữ lập trình khác là sử dụng các kết nối socket. Tuy nhiên, Rollkit hiện không có khả năng giao tiếp tự nhiên với các ứng dụng sử dụng ổ cắm, điều này có thể hạn chế tốc độ di chuyển của các máy ảo hoặc ứng dụng khác.
Mặt khác, OP Stack có yêu cầu riêng về giao diện giống ABCI, được gọi là Engine API, đang được phát triển, bất kỳ VM nào được tích hợp vào OP Stack đều phải tương thích với Engine API.
Hình 4. Cấu trúc Rollkit
(3) Rollkit có thể được tích hợp vào các chuỗi không phải EVM (chẳng hạn như Bitcoin) để kế thừa tính bảo mật của nó, nhưng OP Stack thì không thể
Đối với OP Stack, nó phải dựa vào chuỗi bên thứ ba làm lớp quyết toán của các chuỗi OP Stack khác, yêu cầu triển khai ứng máy trạm nhẹ hoặc hợp đồng thông minh của chuỗi nguồn trên lớp quyết toán .
Việc sử dụng các chuỗi không tương thích với EVM làm lớp quyết toán yêu cầu mỗi chuỗi phải hiểu và xác minh bằng chứng cũng như trạng thái của các hệ thống VM khác. Điều này đòi hỏi quá trình phức tạp trong việc xây dựng máy trạm nhẹ hoặc client đầy đủ của nhau. Tuy nhiên, gần như không thể xây dựng một máy trạm nhẹ/đầy đủ của OP Stack trên một chuỗi như Bitcoin , khiến tích hợp vào Bitcoin gần như không thể.
Tuy nhiên, vì chủ quyền Rollup được chứng minh thông qua xác minh máy trạm nhẹ của chính nó nên việc lấy dữ liệu Bitcoin để sử dụng làm lớp DA có thể tương đối dễ dàng.
(4) chủ quyền Rollup Bitcoin không thể kế thừa giá trị từ Bitcoin
chủ quyền Rollup Bitcoin sử dụng Bitcoin làm lớp DA và xác minh bằng chứng ngoài chuỗi, nhưng nó có thể kế thừa mức độ bảo mật từ Bitcoin đến mức nào?
Vì gần như không thể viết một máy trạm đầy đủ hoặc nhẹ cho chủ quyền Rollup trên Bitcoin . Điều này có nghĩa là nếu không có cầu nối tín nhiệm để di chuyển tài sản giữa Bitcoin và chủ quyền Rollup của nó thì việc giải thích các bằng chứng và trạng thái từ chủ quyền Rollup là không thể.
Sreeram Kannan cung cấp một khuôn khổ tuyệt vời đánh giá tính bảo mật blockchain. Áp dụng khuôn khổ này để đánh giá tính bảo mật của chủ quyền Rollup Bitcoin , chúng tôi thấy rằng khả năng chống tổ chức lại, khả năng chống kiểm duyệt và tính khả dụng dữ liệu có thể được kế thừa từ Bitcoin , chỉ để lại các thuộc tính hợp lệ là những thách thức đặc biệt.
Hình 5. Tính bảo mật của chủ quyền Rollup Bitcoin
Do đó, Bitcoin chủ quyền Rollup không phù hợp với các ứng dụng yêu cầu sử dụng BTC nguyên gốc hoặc yêu cầu khả năng kết hợp logic ứng dụng khác trên Bitcoin. Tuy nhiên, nó có thể là một lựa chọn tốt cho các dự án ưu tiên khả năng chống kiểm duyệt và chống lại việc tổ chức lại, chẳng hạn như các dự án NFT.
Tuy nhiên, liệu Bitcoin có thể là lớp sẵn có dữ liệu phù hợp cho chủ quyền Rollup của nó không? Các nhân chứng của Taproot cung cấp cho Bitcoin khả năng bao gồm tối đa 4MB dữ liệu tùy ý trong mỗi khối. Mặc dù chi phí lưu trữ dữ liệu chủ quyền Rollup vẫn còn được thảo luận thêm, nhưng theo người sáng lập Taproot Eric Wall, nó có thể rẻ hơn 7 lần so với Ethereum trên cơ sở byte.
3.2 SDK có chủ quyền của ZK và Bản tổng hợp dàn quyết toán ZK
Quá trình tổng hợp ZK sẽ có thời gian hoàn thiện nhanh hơn so với quá trình tổng hợp lạc quan, nhưng do chi phí xác minh bằng chứng cao nên quá trình tổng hợp ZK vẫn phải chịu thời gian hoàn thiện lâu hơn.
Chi phí xác minh một bằng chứng duy nhất trong quá trình tổng hợp Ethereum có thể dao động từ 300.000 đến 5 triệu gas , tùy thuộc vào hệ thống bằng chứng cơ bản. Tuy nhiên, quy mô của bằng chứng tăng trưởng chậm theo số lượng giao dịch. Do đó, rollup thường chọn cách chờ đợi và tích lũy các lô giao dịch để khấu hao chi phí xác minh bằng chứng của mỗi giao dịch.
Lý do chính khiến thời gian hoàn thiện ZK trong quá trình quyết toán ZK hiện tại kéo dài là do sự chậm trễ trong việc giảm chi phí. Tuy nhiên, bằng cách sử dụng và tín nhiệm một sắp xếp tập trung, quá trình tổng hợp quyết toán ZK có thể đạt được "cuối cùng mềm" nhanh hơn.
Từ quan điểm này, SDK có chủ quyền mang lại lợi thế duy nhất là cho phép hoàn thiện nhanh chóng và “đúng” bằng cách giảm chi phí xác minh. Nút trong chủ quyền Rollup có thể tạo bằng chứng trong thời gian thực và tổng hợp chúng thành một loạt bằng chứng sau đó bằng cách sử dụng đệ quy. Ngoài ra, chủ quyền Rollup không yêu cầu thêm chi phí xác minh trên chuỗi, điều này giúp loại bỏ thời gian chờ đợi bổ sung cần thiết để phân bổ chi phí giao dịch.
Một lần nữa, việc hoàn thiện vẫn bị hạn chế bởi DA và lớp đồng thuận, nhưng sự chậm trễ do chi phí xác minh bằng chứng cao có thể giảm đáng kể.
3.3 Bản cuộn nhúng (Dymension)
Như đã đề cập ở trên, tổng hợp được nhúng có nghĩa là xây dựng khối tổng hợp trong chính L1. Trong Ethereum, máy trạm thực thi xây dựng các khối chứa Block Header và nội dung khối. Nếu chúng tôi gói khối này dưới dạng khối tổng hợp có bằng chứng (zk/lừa đảo), thì những người xác thực khác không cần tính toán lại tất cả các giao dịch. Thay vào đó, họ chỉ cần tính toán sự khác biệt trạng thái và xác minh bằng chứng.
Điều này có thể mang lại một số lợi thế:
- Không cần thực hiện lại và đặc biệt phù hợp với giải pháp chứng thực nhà nước. Điều này cũng có thể tăng tốc quá trình đồng bộ hóa nút do tải lịch sử nhẹ.
- Hầu như tất cả các giá trị sẽ chuyển thẳng đến L1 - Dymension Hub.
- Không cần phải xây dựng hợp đồng cầu nối ở lớp quyết toán, cho phép độ trễ nhỏ hơn và hoàn thiện nhanh hơn.
Việc kết hợp cuộn nội tuyến vào Ethereum rất khó, đó là lý do tại sao các dự án như Dymension chọn xây dựng trong hệ sinh thái Cosmos .
Tuy nhiên, vấn đề tiềm ẩn lớn nhất với SDK tổng hợp được nhúng là nó thiếu tính linh hoạt và chủ quyền. Logic cơ bản của việc sản xuất khối, xác minh bằng chứng và các loại tổng hợp được "nhúng" vào lớp quyết toán và không thể được các nhà phát triển tự do sửa đổi hoặc "Legoized".
Do đó, SDK tổng hợp được nhúng (chẳng hạn như Dymension) được kết nối chặt chẽ với lớp quyết toán của nó, khiến việc tự do sửa đổi từng mô-đun của Rollup như Rollkit hoặc Sovereign SDK trở nên khó khăn.
3.4 Các tính năng chính của SDK tổng hợp là gì?
Mô-Đun thúc đẩy khả năng kết hợp. Ví dụ: SDK mô-đun có thể được tùy chỉnh và triển khai cho các mục đích sử dụng khác nhau, từ DEX đến các dự án trò chơi yêu cầu TPS cao, bằng cách kết hợp nhiều mô-đun khác nhau, từ hoàn cảnh thực thi đến các giải pháp kiểm chứng. Mô-Đun phát triển càng cụ thể có thể được tích hợp trơn tru vào cùng một SDK thì khả năng kết hợp càng cao, từ đó giảm đáng kể rào cản sử dụng.
Tuy nhiên, mô-đun cũng yêu cầu giao diện thống nhất. Việc có giao diện chuẩn sẽ giúp việc thay thế linh kiện dễ dàng hơn. Ngược lại, các giao diện khác nhau có thể dẫn đến sự phân mảnh của hệ sinh thái tổng hợp ứng dụng. Trong trường hợp không có giao diện thống nhất, sẽ có rủi ro xảy ra các bộ LEGO không tương thích với nhau. Giao diện hợp nhất sẽ mang lại mô-đun. Ngược lại, mô-đun mang lại khả năng kết hợp, mở ra tiềm năng cho nhiều bản tổng hợp ứng dụng.
Hình 6. Mô-Đun và khả năng kết hợp
