Giải mã phương án kỹ thuật Merlin: Nó hoạt động như thế nào?
Tuyển chọn TechFlowTuyển chọn TechFlow
Giải mã phương án kỹ thuật Merlin: Nó hoạt động như thế nào?
Giúp nhiều người hơn hiểu được quy trình làm việc tổng thể của Merlin, từ đó có nhận thức rõ ràng hơn về mô hình bảo mật của nó.
Chuyên sâu báo cáo Web3Tác giả: Faust, Geeker web3
Từ mùa铭文 năm 2023 đến nay, Bitcoin Layer2 luôn là chủ đề trọng tâm của toàn bộ Web3. Dù lĩnh vực này trỗi dậy muộn hơn nhiều so với Ethereum Layer2, nhưng nhờ sức hút độc đáo từ cơ chế POW và việc ra mắt thành công ETF giao ngay, Bitcoin – không cần lo ngại rủi ro "chứng khoán hóa" – trong vòng chưa đầy nửa năm đã thu hút sự chú ý của hàng chục tỷ USD vốn đầu tư vào phân nhánh Layer2.
Trong thị trường Bitcoin Layer2, Merlin – sở hữu TVL lên tới hàng chục tỷ USD – rõ ràng là dự án lớn nhất và được quan tâm nhiều nhất. Nhờ chính sách staking rõ ràng và lợi suất hấp dẫn, Merlin gần như vươn lên mạnh mẽ chỉ trong vài tháng, tạo nên một huyền thoại hệ sinh thái vượt cả Blast. Cùng với sự nổi tiếng ngày càng tăng của Merlin, các thảo luận về giải pháp kỹ thuật của nó cũng trở thành chủ đề được nhiều người quan tâm.
Trong bài viết này, Geeker web3 sẽ tập trung vào giải pháp kỹ thuật của Merlin Chain, phân tích tài liệu công khai cùng định hướng thiết kế giao thức, nhằm giúp mọi người hiểu rõ quy trình hoạt động tổng thể của Merlin, có cái nhìn rõ ràng hơn về mô hình bảo mật của nó, để mỗi người đều có thể trực quan hóa cách vận hành của “Bitcoin Layer2 hàng đầu” này.
Mạng lưới Oracle phi tập trung của Merlin: Ủy ban DAC mở ngoài chuỗi
Đối với mọi Layer2, dù là Ethereum Layer2 hay Bitcoin Layer2, thì DA (Data Availability) và chi phí phát hành dữ liệu luôn là một trong những vấn đề then chốt cần giải quyết. Vì bản thân mạng Bitcoin tồn tại nhiều hạn chế, vốn dĩ không hỗ trợ lưu lượng dữ liệu lớn, nên việc tận dụng hiệu quả không gian DA quý giá này trở thành thử thách trí tưởng tượng của các đội phát triển Layer2.
Có một kết luận hiển nhiên: nếu Layer2 "trực tiếp" phát hành dữ liệu giao dịch chưa xử lý lên khối Bitcoin, thì vừa không đạt được thông lượng cao, lại vừa không giảm được phí giao dịch. Giải pháp phổ biến nhất hiện nay là hoặc nén dữ liệu ở mức tối đa trước khi tải lên khối Bitcoin, hoặc phát hành dữ liệu trực tiếp bên ngoài chuỗi Bitcoin.
Trong số các Layer2 theo hướng thứ nhất, nổi bật nhất có thể kể đến Citrea, họ dự định tải lên mạng Bitcoin sự thay đổi trạng thái (state diff) của Layer2 trong một khoảng thời gian nhất định – tức là kết quả thay đổi trạng thái của nhiều tài khoản – kèm theo bằng chứng ZK tương ứng. Trong trường hợp này, bất kỳ ai cũng có thể tải về state diff và ZKP từ mạng chính Bitcoin để theo dõi kết quả thay đổi trạng thái của Citrea. Phương pháp này có thể nén kích thước dữ liệu trên chuỗi hơn 90%.
Dù phương pháp này tiết kiệm đáng kể kích thước dữ liệu, nhưng điểm nghẽn vẫn rất rõ ràng. Nếu trong thời gian ngắn, có quá nhiều tài khoản thay đổi trạng thái, Layer2 phải tổng hợp và tải lên mạng Bitcoin tất cả các thay đổi này, chi phí phát hành dữ liệu cuối cùng khó có thể giảm xuống mức thấp – điều này dễ thấy ở nhiều ZK Rollup trên Ethereum.
Nhiều Bitcoin Layer2 chọn luôn con đường thứ hai: sử dụng giải pháp DA ngoài chuỗi, tự xây lớp DA hoặc dùng Celestia, EigenDA... B^Square, BitLayer và nhân vật chính của bài viết này – Merlin – đều theo đuổi phương án mở rộng DA ngoài chuỗi.
Trong bài viết trước đây của Geeker web3 – “Phân tích lộ trình kỹ thuật mới của B^2: Tính cần thiết của lớp DA ngoài chuỗi Bitcoin và lớp xác minh” – chúng tôi từng đề cập, B^2 sao chép trực tiếp Celestia, xây dựng một mạng DA hỗ trợ lấy mẫu dữ liệu ngoài chuỗi mang tên B^2 Hub. Các dữ liệu DA như dữ liệu giao dịch hay state diff được lưu trữ ngoài chuỗi Bitcoin, chỉ tải datahash / merkle root lên mạng chính Bitcoin.
Thực chất, điều này coi Bitcoin như một bảng thông báo phi tin cậy: bất kỳ ai cũng có thể đọc datahash từ chuỗi Bitcoin. Khi bạn nhận dữ liệu DA từ nhà cung cấp dữ liệu ngoài chuỗi, bạn có thể kiểm tra xem nó có khớp với datahash trên chuỗi hay không, tức là hash(data1) == datahash1?. Nếu có mối liên hệ, chứng tỏ dữ liệu mà nhà cung cấp ngoài chuỗi đưa cho bạn là đúng.
(Sơ đồ nguyên lý Layer2 có lớp DA nằm ngoài Bitcoin, nguồn ảnh: Geeker web3)
Quy trình trên đảm bảo dữ liệu do nút ngoài chuỗi cung cấp có liên hệ với "dấu vết" nào đó trên Layer1, ngăn ngừa việc lớp DA cố tình cung cấp dữ liệu sai lệch. Nhưng ở đây tồn tại một kịch bản xấu rất quan trọng: nếu nguồn dữ liệu – Sequencer – hoàn toàn không phát hành dữ liệu tương ứng với datahash, chỉ gửi datahash lên chuỗi Bitcoin mà cố tình giữ lại dữ liệu khiến không ai đọc được, thì phải làm sao?
Các kịch bản tương tự bao gồm: chỉ phát hành ZK-Proof và StateRoot mà không công bố dữ liệu DA tương ứng (state diff hoặc dữ liệu giao dịch). Người dùng tuy có thể xác minh ZKProof, khẳng định quá trình tính toán từ Prev_Stateroot sang New_Stateroot là hợp lệ, nhưng lại không biết tài khoản nào đã thay đổi trạng thái. Trong trường hợp này, dù tài sản người dùng an toàn, nhưng không ai xác định được trạng thái thực tế của mạng, không biết giao dịch nào đã được đóng gói, hợp đồng nào đã cập nhật trạng thái – lúc này Layer2 về cơ bản coi như ngừng hoạt động.
Đây chính là “giữ lại dữ liệu” (data withholding). Dankrad thuộc Quỹ Ethereum từng thảo luận đơn giản về vấn đề tương tự trên Twitter vào tháng 8 năm 2023, mặc dù ông chủ yếu nói về một thứ gọi là “DAC”.
Nhiều Ethereum Layer2 sử dụng giải pháp DA ngoài chuỗi thường thiết lập vài nút có quyền đặc biệt, tạo thành một ủy ban – Data Availability Committee (DAC). Ủy ban DAC này đóng vai trò người bảo lãnh, tuyên bố rằng: Sequencer thực sự đã phát hành đầy đủ dữ liệu DA (dữ liệu giao dịch hoặc state diff) ngoài chuỗi. Sau đó, các nút DAC cùng ký đa chữ ký, chỉ cần đạt ngưỡng yêu cầu (ví dụ 2/4), hợp đồng liên quan trên Layer1 sẽ mặc định Sequencer đã qua kiểm tra của ủy ban DAC, đã phát hành đầy đủ dữ liệu DA ngoài chuỗi.
Ủy ban DAC của Ethereum Layer2 chủ yếu tuân theo mô hình POA, chỉ cho phép một số ít nút đã qua KYC hoặc do chính thức chỉ định tham gia, khiến DAC trở thành biểu tượng của “tập trung hóa”, “liên minh chuỗi”. Thêm nữa, ở một số Ethereum Layer2 dùng mô hình DAC, sequencer chỉ gửi dữ liệu DA cho các nút thành viên DAC, hầu như không tải dữ liệu đi đâu khác. Bất kỳ ai muốn lấy dữ liệu DA đều phải được ủy ban DAC cho phép – chẳng khác gì một liên minh chuỗi.
Rõ ràng, DAC nên được phi tập trung hóa. Layer2 có thể không tải dữ liệu DA trực tiếp lên Layer1, nhưng quyền tham gia ủy ban DAC nên mở cửa, để ngăn chặn âm mưu xấu từ một nhóm nhỏ. (Việc thảo luận về kịch bản DAC làm điều xấu có thể tham khảo bài đăng trước đây của Dankrad trên Twitter)
BlobStream mà Celestia từng đề xuất về bản chất là dùng Celestia thay thế DAC tập trung: sequencer của Ethereum L2 có thể phát hành dữ liệu DA lên chuỗi Celestia, nếu 2/3 nút Celestia ký xác nhận, hợp đồng riêng của Layer2 triển khai trên Ethereum sẽ cho rằng sequencer đã phát hành dữ liệu DA trung thực – thực tế là dùng nút Celestia làm người bảo lãnh. Với hàng trăm nút Validator Celestia, ta có thể coi DAC khổng lồ này khá phi tập trung.
Giải pháp DA mà Merlin sử dụng khá giống BlobStream của Celestia, đều mở quyền tham gia DAC theo hình thức POS để hướng tới phi tập trung. Bất kỳ ai đặt cược đủ tài sản đều có thể vận hành một nút DAC. Trong tài liệu của Merlin, các nút DAC này được gọi là Oracle, và chỉ ra rằng sẽ hỗ trợ đặt cược bằng BTC, MERL, thậm chí cả token BRC-20, tạo cơ chế staking linh hoạt, cũng hỗ trợ staking đại diện kiểu Lido. (Giao thức staking POS cho Oracle là một trong những câu chuyện cốt lõi sắp tới của Merlin, lãi suất staking được cung cấp khá cao)
Dưới đây tóm tắt quy trình hoạt động của Merlin (hình ảnh ở dưới):
- Sequencer nhận được nhiều yêu cầu giao dịch, tổng hợp thành batch dữ liệu (data batch), gửi đến nút Prover và nút Oracle (DAC phi tập trung).
- Nút Prover của Merlin là phi tập trung, sử dụng dịch vụ Prover as a Service của Lumoz. Kho thợ đào Prover sau khi nhận nhiều data batch sẽ tạo bằng chứng ZK tương ứng, rồi gửi ZKP đến nút Oracle để họ xác minh.
- Nút Oracle xác minh xem ZK Proof do kho đào ZK của Lumoz gửi có khớp với data batch mà Sequencer gửi hay không. Nếu khớp và không có lỗi, xác minh thành công. Trong quá trình này, các nút Oracle phi tập trung dùng chữ ký ngưỡng (threshold signature) để tạo chữ ký đa, tuyên bố rằng: sequencer đã phát hành đầy đủ dữ liệu DA, và ZKP tương ứng là hợp lệ, đã qua xác minh của các nút Oracle.
- Sequencer thu thập kết quả chữ ký đa từ các nút Oracle, khi số lượng chữ ký đạt ngưỡng yêu cầu, sẽ gửi thông tin chữ ký này lên chuỗi Bitcoin, kèm theo datahash của dữ liệu DA (data batch), để bên ngoài đọc và xác nhận.
(Sơ đồ nguyên lý hoạt động Merlin, nguồn ảnh: Geeker web3)
- Các nút Oracle xử lý đặc biệt quá trình xác minh tính toán ZK Proof, tạo Commitment (lời cam kết), gửi lên chuỗi Bitcoin, cho phép bất kỳ ai thách thức "lời cam kết" này, quy trình này về cơ bản giống giao thức bằng chứng gian lận (fraud proof) của bitVM. Nếu thách thức thành công, nút Oracle phát hành Commitment sẽ bị phạt kinh tế. Tất nhiên, dữ liệu Oracle cần phát hành lên chuỗi Bitcoin còn bao gồm hash trạng thái hiện tại của Layer2 – StateRoot, và bản thân ZKP – đều phải công bố để bên ngoài kiểm tra.
Tài liệu tham khảo: “Giải thích đơn giản BitVM: Cách xác minh bằng chứng gian lận trên chuỗi BTC”
Còn vài chi tiết cần làm rõ: trước tiên, lộ trình của Merlin đề cập, trong tương lai sẽ yêu cầu Oracle sao lưu dữ liệu DA lên Celestia, như vậy các nút Oracle có thể loại bỏ dữ liệu lịch sử cục bộ một cách phù hợp, không cần lưu dữ liệu mãi mãi tại chỗ. Đồng thời, Commitment do Mạng Oracle tạo ra thực chất là gốc của một cây Merkle. Chỉ công bố root là chưa đủ, cần phải công khai toàn bộ tập dữ liệu tương ứng với Commitment, vì vậy cần tìm một nền tảng DA bên thứ ba, nền tảng này có thể là Celestia hoặc EigenDA, hoặc lớp DA khác.
Tài liệu tham khảo: “Phân tích lộ trình kỹ thuật mới của B^2: Tính cần thiết của lớp DA ngoài chuỗi Bitcoin và lớp xác minh”
Phân tích mô hình bảo mật: ZKRollup lạc quan + Dịch vụ MPC của Cobo
Ở trên chúng tôi đã tóm tắt quy trình hoạt động của Merlin, hy vọng bạn đã nắm được cấu trúc cơ bản của nó. Ta dễ dàng nhận thấy, Merlin, B^Square, BitLayer, Citrea đều cơ bản tuân theo cùng mô hình bảo mật – ZK-Rollup lạc quan.
Lần đầu đọc cụm từ này, có thể khiến nhiều người yêu thích Ethereum cảm thấy kỳ lạ, “ZK-Rollup lạc quan” nghĩa là gì? Trong nhận thức cộng đồng Ethereum, "mô hình lý thuyết" của ZK Rollup hoàn toàn dựa trên độ tin cậy của tính toán mật mã, không cần giả định tin cậy, trong khi từ “lạc quan” lại giới thiệu giả định tin cậy – nghĩa là, trong phần lớn thời gian, mọi người phải lạc quan cho rằng Rollup không có lỗi, là đáng tin cậy. Khi xảy ra lỗi, có thể trừng phạt người vận hành Rollup thông qua bằng chứng gian lận – đây chính là nguồn gốc tên gọi Optimistic Rollup, còn gọi là OP Rollup.
Đối với hệ sinh thái Ethereum – cái nôi của Rollup – thì ZK-Rollup lạc quan có vẻ hơi kỳ dị, nhưng điều này lại phù hợp với thực trạng Bitcoin Layer2. Do giới hạn kỹ thuật, chuỗi Bitcoin không thể xác minh đầy đủ ZK Proof, chỉ có thể xác minh từng bước tính toán ZKP trong trường hợp đặc biệt. Trong bối cảnh này, chuỗi Bitcoin thực tế chỉ hỗ trợ giao thức bằng chứng gian lận: người dùng có thể chỉ ra một bước tính toán sai trong quá trình xác minh ZKP ngoài chuỗi, rồi thách thức thông qua bằng chứng gian lận. Dù không thể sánh với ZK Rollup kiểu Ethereum, nhưng đây đã là mô hình bảo mật đáng tin cậy và ổn định nhất mà Bitcoin Layer2 có thể đạt được hiện nay.
Trong mô hình ZK-Rollup lạc quan trên, giả sử có N người có quyền thách thức trong mạng Layer2, chỉ cần trong số N người thách thức này có 1 người trung thực, luôn có thể phát hiện lỗi và khởi động bằng chứng gian lận, thì việc chuyển đổi trạng thái Layer2 là an toàn. Tất nhiên, một Optimistic Rollup hoàn chỉnh cần đảm bảo cầu rút tiền của nó cũng được bảo vệ bởi giao thức bằng chứng gian lận, nhưng hiện tại gần như tất cả Bitcoin Layer2 đều không thể đáp ứng điều kiện này, phải phụ thuộc vào đa ký / MPC. Vậy lựa chọn giải pháp đa ký / MPC nào trở thành vấn đề liên quan mật thiết đến độ an toàn của Layer2.
Merlin chọn dịch vụ MPC của Cobo cho giải pháp cầu nối, áp dụng các biện pháp như cách ly ví nóng/ví lạnh, tài sản cầu nối do Cobo và Merlin Chain cùng quản lý, mọi hành vi rút tiền cần sự xử lý chung từ các bên tham gia MPC của Cobo và Merlin Chain – về bản chất là dựa vào uy tín tổ chức để đảm bảo độ tin cậy của cầu rút tiền. Tất nhiên, đây chỉ là giải pháp tạm thời ở giai đoạn hiện tại. Khi dự án dần hoàn thiện, cầu rút tiền có thể được thay thế bằng "cầu lạc quan" với giả định tin cậy 1/N thông qua việc tích hợp BitVM và giao thức bằng chứng gian lận, dù độ khó triển khai như vậy sẽ rất lớn (hiện tại gần như tất cả cầu chính thức của Layer2 đều phụ thuộc vào đa ký).
Nhìn chung, ta có thể tóm lại: Merlin đưa vào DAC dựa trên POS, ZK-Rollup lạc quan dựa trên BitVM, và giải pháp quản lý tài sản MPC của Cobo, giải quyết vấn đề DA bằng cách mở quyền truy cập DAC; đảm bảo an toàn chuyển đổi trạng thái bằng cách tích hợp BitVM và giao thức bằng chứng gian lận; đảm bảo độ tin cậy cầu rút tiền nhờ dịch vụ MPC từ nền tảng quản lý tài sản nổi tiếng Cobo.
Giải pháp nộp ZKP theo hai bước dựa trên Lumoz
Phía trên chúng tôi đã phác họa mô hình bảo mật của Merlin, giới thiệu khái niệm ZK-rollup lạc quan. Trong lộ trình kỹ thuật của Merlin, còn đề cập đến Prover phi tập trung. Ai cũng biết, Prover là vai trò cốt lõi trong kiến trúc ZK-Rollup, chịu trách nhiệm tạo ZKProof cho Batch do Sequencer phát hành, trong khi quá trình tạo bằng chứng kiến thức không lại tiêu tốn rất nhiều tài nguyên phần cứng – đây là vấn đề nan giải.
Để tăng tốc độ tạo bằng chứng ZK, chia nhỏ tác vụ để xử lý song song là thao tác cơ bản nhất. Song song hóa nghĩa là chia nhiệm vụ tạo bằng chứng ZK thành các phần khác nhau, giao cho các Prover khác nhau hoàn thành riêng biệt, cuối cùng Aggregator (bộ tổng hợp) gom nhiều đoạn Proof thành một bằng chứng duy nhất.
Để tăng tốc quá trình tạo bằng chứng ZK, Merlin sẽ sử dụng giải pháp Prover as a service của Lumoz – thực chất là tập hợp nhiều thiết bị phần cứng thành một mỏ đào, phân bổ tác vụ tính toán cho các thiết bị khác nhau, đồng thời phân phối phần thưởng tương ứng, khá giống đào POW.
Trong giải pháp Prover phi tập trung này, tồn tại một dạng tấn công, gọi là tấn công front-running: giả sử một Aggregator đã tạo xong ZKP, gửi đi để nhận thưởng. Các Aggregator khác thấy nội dung ZKP, chạy trước và phát hành nội dung tương tự, tuyên bố ZKP này do họ tạo trước, thì phải giải quyết thế nào?
Giải pháp bản năng đầu tiên mọi người nghĩ đến có lẽ là phân bổ mã nhiệm vụ riêng cho từng Aggregator, ví dụ nhiệm vụ 1 chỉ Aggregator A được nhận, người khác dù hoàn thành cũng không nhận được thưởng. Nhưng phương pháp này có nhược điểm: không chống được rủi ro điểm đơn. Nếu Aggregator A gặp sự cố hiệu suất hoặc mất kết nối, nhiệm vụ 1 sẽ bị đình trệ mãi. Hơn nữa, việc giao nhiệm vụ cho một thực thể duy nhất không thể thúc đẩy hiệu suất sản xuất bằng cơ chế khuyến khích cạnh tranh – không phải là cách hay.
Polygon zkEVM từng đề xuất trong một bài blog phương pháp gọi là Proof of efficiency, cho rằng nên dùng biện pháp cạnh tranh để các Aggregator đua nhau, phân bổ phần thưởng theo nguyên tắc ai nhanh hơn được trước, Aggregator nào nộp ZK-Proof lên chuỗi sớm nhất sẽ nhận thưởng. Tuy nhiên, bài viết đó không đề cập cách giải quyết vấn đề MEV front-running.
Lumoz sử dụng phương pháp nộp bằng chứng ZK hai bước: sau khi một Aggregator tạo xong ZK Proof, chưa cần phát nội dung đầy đủ, mà chỉ cần công bố hash của ZKP – nói cách khác, công bố hash(ZKP + Địa chỉ Aggregator). Như vậy, dù người khác thấy giá trị hash, họ cũng không biết nội dung ZKP tương ứng, không thể chạy trước trực tiếp;
Nếu có người sao chép toàn bộ hash và phát trước, cũng vô ích, vì hash chứa địa chỉ của Aggregator X cụ thể, dù Aggregator A có phát trước hash này, khi ảnh gốc (pre-image) của hash được tiết lộ, mọi người cũng thấy địa chỉ Aggregator bên trong là X chứ không phải A.
Thông qua giải pháp nộp ZKP hai bước này, Merlin (Lumoz) có thể giải quyết vấn đề front-running trong quá trình nộp ZKP, từ đó tạo cơ chế khuyến khích tạo bằng chứng kiến thức không cao độ cạnh tranh, nâng cao tốc độ tạo ZKP.
Merlin's Phantom: Tương tác đa chuỗi
Theo lộ trình kỹ thuật của Merlin, họ còn hỗ trợ tương tác giữa Merlin và các chuỗi EVM khác, đường đi thực hiện về cơ bản giống ý tưởng trước đây của Zetachain. Nếu lấy Merlin làm chuỗi nguồn, các chuỗi EVM khác làm chuỗi đích, khi nút Merlin nhận được yêu cầu tương tác xuyên chuỗi từ người dùng, sẽ kích hoạt quy trình làm việc tiếp theo trên chuỗi đích.
Ví dụ, có thể triển khai một tài khoản EOA do mạng Merlin kiểm soát trên Polygon. Khi người dùng phát hành lệnh tương tác xuyên chuỗi trên Merlin Chain, mạng Merlin trước tiên phân tích nội dung, tạo dữ liệu giao dịch để thực thi trên chuỗi đích, sau đó mạng Oracle xử lý chữ ký MPC cho giao dịch này, tạo chữ ký số. Tiếp theo, nút Relayer của Merlin phát hành giao dịch này trên Polygon, sử dụng tài sản trong tài khoản EOA của Merlin trên chuỗi đích để hoàn thành các thao tác tiếp theo.
Sau khi thao tác yêu cầu của người dùng hoàn tất, tài sản tương ứng sẽ được chuyển trực tiếp đến địa chỉ của người dùng trên chuỗi đích, về lý thuyết cũng có thể chuyển thẳng về Merlin Chain. Giải pháp này có một số lợi ích rõ rệt: tránh được hao mòn phí giao dịch khi chuyển tài sản truyền thống qua cầu nối và hợp đồng cầu, đồng thời an toàn của thao tác xuyên chuỗi được đảm bảo trực tiếp bởi mạng Oracle của Merlin, không cần dựa vào hạ tầng bên ngoài. Miễn người dùng tin tưởng Merlin Chain, có thể mặc định các hành vi tương tác xuyên chuỗi như vậy là không có vấn đề.
Tổng kết
Trong bài viết này, chúng tôi đã giải thích sơ lược giải pháp kỹ thuật tổng thể của Merlin Chain, hy vọng giúp nhiều người hơn hiểu được quy trình hoạt động cơ bản của Merlin, có nhận thức rõ ràng hơn về mô hình bảo mật của nó. Trước bối cảnh hệ sinh thái Bitcoin đang bùng nổ, chúng tôi cho rằng các hoạt động phổ biến kiến thức kỹ thuật như thế này là có giá trị và được đông đảo công chúng cần đến. Chúng tôi sẽ theo dõi dài hạn các dự án như Merlin, bitLayer, B^Square trong tương lai, phân tích sâu hơn các giải pháp kỹ thuật của họ – kính mời quý vị đón chờ!
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
@godrealmx
