Bản ghi bài phát biểu của Vitalik Buterin tại Hội chợ Web3 Hồng Kông: Chúng ta cần những giao thức có thể đạt đến giới hạn của công nghệ mã hóa
Tuyển chọn TechFlowTuyển chọn TechFlow
Bản ghi bài phát biểu của Vitalik Buterin tại Hội chợ Web3 Hồng Kông: Chúng ta cần những giao thức có thể đạt đến giới hạn của công nghệ mã hóa
Chúng ta thực sự cần bắt đầu nghiên cứu xem giới hạn trên là gì, và làm thế nào chúng ta mới có thể thực sự đạt đến giới hạn trên đó.
Chuyên sâu báo cáo Web3Tác giả: Vitalik Buterin
Tổng hợp: DeThings
Trong khuôn khổ sự kiện Web3 Festival Hồng Kông 2024, đồng sáng lập Ethereum Vitalik Buterin đã có bài phát biểu chính tại "Hội nghị Thượng đỉnh Học giả Web3 2024" do DRK Lab tổ chức với chủ đề “Reaching the Limits of Protocol Design”.
Dưới đây là bản ghi trực tiếp bằng tiếng Trung do DeThings thực hiện, có lược bỏ:
Trong 10 năm qua, các loại công nghệ dùng để xây dựng giao thức đã thay đổi rất lớn. Khi Bitcoin ra đời vào năm 2009, nó thực tế sử dụng những kỹ thuật mã hóa rất đơn giản; loại mật mã duy nhất bạn thấy trong giao thức Bitcoin là hàm băm và chữ ký ECDSA đường cong elliptic, cùng bằng chứng công việc (PoW). Bằng chứng công việc chỉ là một cách khác để sử dụng hàm băm. Nếu nhìn vào các loại công nghệ được dùng để xây dựng giao thức trong thập niên 2020, bạn sẽ bắt đầu thấy một tập hợp các công nghệ phức tạp hơn nhiều, những thứ thực sự mới nổi lên trong 10 năm vừa qua.
Những thứ này thực tế đã tồn tại rất lâu rồi, vì vậy về mặt kỹ thuật, chúng ta đã có định lý PCP trong vài thập kỷ. Từ khi Craig Gentry khám phá ra mã hóa đồng dạng toàn phần vào năm 2009, chúng ta đã sở hữu nó. Chúng ta cũng đã có mạch lộn xộn (garbled circuits) trong nhiều thập kỷ – một dạng tính toán giữa hai bên. Nhưng có một sự khác biệt giữa việc các công nghệ này tồn tại trên lý thuyết và tồn tại trong thực tiễn.
Thực tế, tôi cho rằng chính lĩnh vực blockchain đóng vai trò lớn, mang lại nguồn lực dồi dào giúp đưa những công nghệ này đến giai đoạn có thể sử dụng thường xuyên trong ứng dụng thông thường.
Nếu bạn xây dựng blockchain vào những năm 2010, bạn giả sử rằng hàm băm và chữ ký là tất cả những gì bạn có. Nhưng nếu quan sát các giao thức được xây dựng vào những năm 2020, họ coi tất cả những thứ này là thành phần then chốt ngay từ đầu.
ZK-SNARKs là công nghệ đột phá đầu tiên ở đây. ZK-SNARKs là một kỹ thuật cho phép chứng minh rằng bạn đã thực hiện một phép tính và nhận được kết quả nào đó. Bạn có thể chứng minh theo cách mà việc xác minh nhanh hơn rất nhiều so với việc tự chạy phép tính đó. Và bạn còn có thể xác minh mà không tiết lộ dữ liệu đầu vào ban đầu.
Sự khác biệt giữa ZK-SNARKs của năm 2010 và ZK-SNARKs được dùng lần đầu tiên trong giao thức Zcash ra mắt tháng 12/2016 so với ZK-SNARKs ngày nay thật sự quá lớn, phải không?
Vì vậy, nhiều dạng mã hóa mới này đã trải qua hành trình từ chỗ hầu như không ai biết, đến thú vui dành cho nhóm nhỏ, rồi trở thành dòng chính, và giờ gần như là thiết lập mặc định — tất cả đã thay đổi và cải thiện mạnh mẽ trong thập kỷ qua.
"Do đó, ZK-SNARKs cực kỳ hữu ích trong cả riêng tư lẫn khả năng mở rộng. Blockchain mang lại rất nhiều lợi ích: tính cởi mở, truy cập không cần quyền hạn, khả năng kiểm chứng toàn cầu. Nhưng tất cả đều đánh đổi bằng hai điều lớn.
Một là riêng tư, hai là khả năng mở rộng. ZK-SNARK trả lại cho bạn cả riêng tư lẫn khả năng mở rộng. Năm 2016, chúng ta chứng kiến giao thức Zcash. Sau đó, chúng ta bắt đầu thấy ngày càng nhiều thứ xuất hiện trong hệ sinh thái Ethereum. Ngày nay, gần như mọi thứ đều bắt đầu sử dụng zkSNARK, tính toán đa phương (MPC), và mã hóa đồng dạng toàn phần (FHE). Người ta hiểu biết ít hơn về MPC và FHE so với zkSNARK, nhưng có những việc nhất định không thể làm được bằng ZK-SNARKs, ví dụ như tính toán riêng tư trên dữ liệu cá nhân của người dùng.
Bỏ phiếu thực tế là một trường hợp sử dụng lớn. Bạn có thể đạt được mức độ riêng tư nhất định nhờ zk-SNARKs. Nhưng nếu muốn có thuộc tính tốt nhất, bạn phải dùng MPC (tính toán đa phương) và FHE (mã hóa đồng dạng toàn phần). Nhiều ứng dụng AI mã hóa cuối cùng cũng dùng MPC và FHE — cả hai nguyên thủy này đều có hiệu suất tăng mạnh trong thập kỷ qua. BLS (Boneh-Lynn-Shacham, chữ ký tập hợp) là một công nghệ thú vị, về cơ bản cho phép bạn lấy một nhóm lớn chữ ký từ hàng ngàn người tham gia khác nhau, rồi xác minh tập hợp đó nhanh như xác minh một chữ ký đơn lẻ.
Tính năng này cực kỳ mạnh mẽ. Chính BLS tập hợp là nền tảng công nghệ cốt lõi của cơ chế đồng thuận Proof-of-Stake hiện đại trên Ethereum. Nếu nhìn vào các cơ chế PoS được xây dựng trước khi có BLS tập hợp, thuật toán thường chỉ hỗ trợ được vài trăm máy xác thực. Trên Ethereum hiện nay, có khoảng 30.000 máy xác thực, mỗi 12 giây gửi một chữ ký. Điều này khả thi được là nhờ dạng mã hóa mới này đã được tối ưu hóa đủ trong 5–10 năm qua để có thể sử dụng — những công nghệ mới này đã làm nên điều không thể”.
Chúng đang nhanh chóng trở nên mạnh mẽ hơn. Các giao thức ngày nay sử dụng rất nhiều các công nghệ này. Chúng ta thực sự đã trải qua bước chuyển lớn từ mật mã chuyên dụng sang mật mã phổ quát — từ thời điểm bạn phải tự hiểu rõ mật mã hoạt động thế nào để tạo giao thức mới, sang thời điểm bạn dùng mật mã phổ quát để tạo thuật toán chuyên dụng cho ứng dụng cụ thể. Trước đây, bạn phải tạo một thuật toán riêng cho từng mục đích riêng; bây giờ, bạn thậm chí không cần là nhà mật mã học để tạo ứng dụng sử dụng những thứ tôi vừa nói trong 5 phút qua.
Bạn chỉ cần viết một đoạn mã, viết code trong Circom, rồi Circom biên dịch nó thành bộ xác minh và bộ kiểm tra, và bạn đã có một ứng dụng zk-SNARK. Thách thức ở đây là gì? Về cơ bản, vấn đề là chúng ta đã đi rất xa trong 10 năm qua. Còn lại gì nữa? Khoảng cách giữa các công nghệ hiện tại và lý tưởng lý thuyết là bao nhiêu? Tôi cho rằng đây chính là lĩnh vực then chốt nơi các nhà nghiên cứu và giới hàn lâm có thể đóng góp lớn.
Tôi nghĩ hai vấn đề lớn hiện nay cơ bản là: một là hiệu suất, hai là an toàn. Giờ có thêm vấn đề thứ ba, có thể gọi là mở rộng chức năng.
Ví dụ, một công nghệ mà chúng ta vẫn chưa thực sự nắm vững là mơ hồ không phân biệt (indistinguishability obfuscation). Nếu chúng ta có một thuật toán khả thi, thì thật tuyệt vời. Nhưng thực tế, tôi cho rằng nâng cao hiệu suất và tăng cường độ an toàn cho những gì chúng ta đang có hôm nay quan trọng hơn”.
Hãy nói về hiệu suất. Hãy lấy một ví dụ cụ thể: blockchain Ethereum. Trên Ethereum, thời gian khe (slot time) là 12 giây. Thời gian trung bình giữa một khối và khối kế tiếp là 12 giây. Thời gian xác minh khối bình thường — tức thời gian bất kỳ nút Ethereum nào cần để xác minh một khối — vào khoảng 400 mili giây.
Hiện nay, thời gian để zk-SNARK xác minh một khối Ethereum điển hình là khoảng 20 phút. Tốc độ này đang cải thiện nhanh — hai năm trước là 5 tiếng. Bây giờ 20 phút là trung bình, đúng không? Vẫn còn trường hợp xấu nhất. Ví dụ, nếu bạn có một khối Ethereum toàn bộ đang thực hiện phép tính Zcash, thì thời gian chứng minh sẽ vượt quá 20 phút.
Tuy nhiên, so với hai năm trước, chúng ta đã tiến xa hơn. Mục tiêu hiện nay là gì? Là chứng minh thời gian thực — khi một khối được tạo ra, bạn có thể nhận được bằng chứng cho khối đó trước khi khối tiếp theo được tạo. Khi có chứng minh thời gian thực, chúng ta sẽ có gì? Về cơ bản, mọi người dùng Ethereum trên thế giới đều có thể dễ dàng trở thành người xác minh đầy đủ cho giao thức Ethereum. Nhưng hiện nay số người chạy nút Ethereum rất ít. Thực tế, một nút lưu trữ đầy đủ cần 2 TB, bạn có thể làm, nhưng rất kém hiệu quả. Làm sao để mọi ví Ethereum, kể cả ví trình duyệt, ví điện thoại, hay ví nhẹ trên các chuỗi khác, đều có thể xác minh hoàn toàn quy tắc đồng thuận Ethereum?
Một số người thực tế không tin Infura. Họ thậm chí không tin các máy xác thực PoS Ethereum, mà trực tiếp xác minh quy tắc, đảm bảo trực tiếp tính đúng đắn của khối Ethereum. Làm sao dùng ZK-SNARK để làm điều này? Để làm thật sự, bằng chứng zK-SNARK cần phải xảy ra thời gian thực, nhưng phải có cách để mọi khối Ethereum đều được chứng minh, có thể trong vòng 5 giây.
Câu hỏi là: Liệu chúng ta có thể đến đó được không? Hiện nay, MPC và FHE cũng có vấn đề tương tự. Như tôi đã nói, một trường hợp điển hình của MPC và FHE là bỏ phiếu, và thực tế đã bắt đầu được sử dụng. Khoảng ba tuần trước, Việt Nam tổ chức một sự kiện Ethereum. Trong sự kiện đó, họ thực tế đã dùng MPC — một trong các hệ thống bỏ phiếu mã hóa an toàn — để bỏ phiếu cho các dự án và hackathon.
Vấn đề hiện tại của MPC là một số thuộc tính an toàn của nó phụ thuộc vào một máy chủ trung tâm. Chúng ta có thể phi tập trung hóa giả định tin cậy này không? Có thể, nhưng điều đó cần MPC và FHE. Vấn đề hiện nay là chi phí hiệu suất để đảm bảo các giao thức này rất lớn, đặc biệt khi kết hợp FHE với ZK-SNARK. Để những giao thức này trở thành mặc định cho người dùng thông thường, thì không thể để mỗi lá phiếu mất 5 đô la Mỹ cho tính toán, đúng không? Nó phải được hoàn thành nhanh, thậm chí xử lý hàng loạt lá phiếu thời gian thực.
Vậy, làm sao để đạt được mục tiêu ZK-SNARK? Tôi nghĩ có ba hướng chính để nâng cao hiệu suất. Một là song song hóa và tập hợp. Hãy tưởng tượng, xác minh một khối Ethereum cần tối đa 10 triệu bước tính toán. Bạn lấy từng bước tính toán đó và tạo một bằng chứng riêng. Sau đó tập hợp các bằng chứng. Lấy hai bằng chứng đầu, chứng minh chúng. Lấy hai bằng chứng tiếp theo, chứng minh chúng. Lấy hai bằng chứng sau nữa, chứng minh chúng. Rồi lấy bằng chứng của hai bằng chứng đầu, chứng minh tiếp — bạn có một cây. Sau khoảng 20 bước đi trên cây, bạn có một bằng chứng lớn đại diện cho tính đúng đắn của toàn bộ khối.
Điều này khả thi với công nghệ hiện nay. Nó có thể chứng minh tính đúng đắn của một khối lý thuyết trong vòng 5 giây. Vấn đề ở đâu? Về cơ bản, điều này cần rất nhiều tính toán song song, đúng không? Cần tới 10 triệu bằng chứng. Vậy ta có thể tối ưu không? Có thể tối ưu hóa song song hóa không? Tối ưu hóa tập hợp bằng chứng không? Câu trả lời là có. Có rất nhiều ý tưởng lý thuyết về cách làm điều này. Nhưng điều này thực sự cần trở thành thứ gì đó thực tế. Đây là vấn đề kết hợp cải tiến thuật toán, cải tiến cấp thấp và thiết kế phần cứng, cải tiến hiệu suất — do đó ASIC cũng rất quan trọng. Chúng ta đều thấy ASIC quan trọng thế nào với khai thác, đúng không? Nhớ lại năm 2013 khi ASIC lần đầu ra mắt, tốc độ băm Bitcoin tăng vọt nhanh thế nào.
ASIC cực kỳ mạnh mẽ, đúng không? Với cùng chi phí phần cứng và điện, ASIC tạo ra hàm băm nhanh hơn GPU khoảng 100 lần. Câu hỏi là: Liệu chúng ta có thể mang lại lợi ích tương tự cho việc chứng minh SNARK không? Tôi nghĩ câu trả lời là có. Vì vậy, ngày càng nhiều công ty bắt đầu thực sự sản xuất ASIC chuyên dụng để chứng minh zK-SNARK. Nó có thể là zkEVMs, nhưng thực tế nên rất phổ quát. Bạn nên có thể chế tạo một ASIC SNARK để chứng minh mọi kiểu tính toán. Làm như vậy, liệu chúng ta có thể rút ngắn từ 20 phút xuống 5 giây không?
Cuối cùng, nâng cao hiệu suất, đúng không? Vì vậy, chúng ta cần các thuật toán zK-SNARK tốt hơn. Chúng ta có Groth16, có bảng tra cứu, có SNARK 64-bit, có STARK, có STARK 32-bit, nhiều ý tưởng khác nhau. Liệu chúng ta có thể nâng cao hiệu suất của thuật toán SNARK hơn nữa không? Có thể tạo ra các hàm băm thân thiện hơn với SNARK, các thuật toán chữ ký thân thiện hơn với SNARK không? Có rất nhiều ý tưởng ở đây, tôi khuyến khích mọi người tập trung vào những ý tưởng này.
Vấn đề an toàn chính là lỗi (bugs), đúng không? Tôi nghĩ lỗi là một trong những vấn đề lớn nhất mà người ta ít nói đến, nhưng lại cực kỳ quan trọng, đúng không? Về cơ bản, chúng ta có tất cả những công nghệ mã hóa tuyệt vời này, nhưng nếu mọi người lo ngại về một lỗi nào đó trong mạch, họ sẽ không tin tưởng chúng, đúng không? Dù là zK-SNARK hay zkEVM, chúng đều có khoảng 7000 dòng mã. Đó là trong tình huống rất hiệu quả. Trung bình, cứ 1000 dòng mã lại có từ 15 đến 50 lỗi. Trên Ethereum, chúng tôi rất cố gắng để giữ dưới 15 lỗi trên 1000 dòng, nhưng vẫn nhiều hơn không, đúng không? Nếu bạn có các hệ thống nắm giữ hàng tỷ đô la tài sản, thì chỉ cần một lỗi trong số đó, mọi tiền bạc sẽ bị mất — dù công nghệ mã hóa có tiên tiến đến đâu.
Câu hỏi là: Chúng ta có thể làm gì để tận dụng công nghệ mã hóa hiện có và giảm thiểu lỗi trong đó? Hiện nay, kỹ thuật cơ bản ở đây là hội đồng an toàn — về cơ bản, bạn chỉ cần tập hợp một nhóm người trong Ethereum, và nếu đa số, ví dụ hơn 75%, cho rằng có lỗi, thì họ có thể bác bỏ mọi thứ mà hệ thống chứng minh nói. Vì vậy, đây là một hệ thống khá tập trung, nhưng là thứ tốt nhất chúng ta có lúc này. Trong tương lai gần, chúng ta sẽ có nhiều lớp chứng minh. Dưới đây là hình ảnh từ Starknet, một trong các Rollup dựa trên Ethereum. Ý tưởng là nếu bạn có nhiều hệ thống chứng minh, về mặt lý thuyết, bạn có thể dùng dư thừa để giảm rủi ro lỗi trong bất kỳ hệ thống nào — nếu bạn có ba hệ thống, hy vọng rằng khi một hệ thống sai, hai hệ thống kia sẽ không sai ở đúng vị trí đó.
Cuối cùng, tôi nghĩ một điều thú vị đáng nghiên cứu trong tương lai là sử dụng công cụ trí tuệ nhân tạo — có thể dùng các công cụ mới để xác minh hình thức, đúng không? Như dùng phương pháp toán học để chứng minh rằng thứ như ZKEVM không có lỗi, đúng không? Về cơ bản, bạn thực sự có thể chứng minh rằng ví dụ, triển khai zkEVM đang xác minh mã EVM chính xác giống như triển khai Ethereum? Ví dụ, bạn có thể chứng minh rằng với mọi đầu vào có thể, chúng chỉ cho ra một đầu ra duy nhất không? Nếu bạn cố gắng thực sự chứng minh những điều này, thì có lẽ trong tương lai, chúng ta có thể thực sự đạt đến thế giới zkEVM không lỗi.
Thật điên rồ, đúng không? Bởi vì trước đây, chưa từng có ai tạo ra chương trình phức tạp như vậy mà không lỗi. Nhưng vào năm 2019, chẳng ai nghĩ AI có thể tạo ra hình ảnh đẹp thật sự, đúng không? Vì vậy, hôm nay chúng ta chỉ đang thấy mình tiến xa thế nào. Chúng ta thấy được khả năng của AI. Câu hỏi bây giờ là: Liệu chúng ta có thể thử áp dụng các công cụ tương tự vào các nhiệm vụ thực tế, như tự động tạo chứng minh toán học cho các câu lệnh phức tạp, các chương trình trải dài hàng ngàn dòng mã không? Tôi nghĩ đây là một thách thức mở thú vị, đáng để mọi người chú ý.
Về hiệu suất chữ ký tập hợp: hiện nay Ethereum có 30.000 máy xác thực, yêu cầu để vận hành một nút rất cao, đúng không? Tôi có một nút Ethereum trên laptop, nó chạy được, nhưng đó không phải laptop rẻ tiền, và tôi phải tự nâng cấp ổ cứng. Mục tiêu lý tưởng của Ethereum là hỗ trợ càng nhiều máy xác thực càng tốt.
Chúng tôi muốn Proof-of-Stake dân chủ hóa tối đa, để mọi người có thể tham gia xác thực ở mọi quy mô. Chúng tôi muốn yêu cầu để vận hành nút Ethereum rất thấp, rất dễ sử dụng. Chúng tôi muốn lý thuyết và giao thức đơn giản tối đa. Giới hạn lý thuyết ở đây là gì? Mỗi người tham gia mỗi chu kỳ cần truyền 1 bit dữ liệu, bởi vì bạn phải phát tín hiệu ai đã tham gia ký tên, ai chưa.
Đây là giới hạn cơ bản nhất,vượt qua giới hạn này, không còn giới hạn nào khác — không có giới hạn dưới về tính toán, bạn có thể làm bằng chứng tập hợp, có thể làm cây bằng chứng đệ quy. Bạn có thể làm chữ ký, có thể làm nhiều dạng chữ ký tập hợp. Bạn có thể dùng STARK, dùng mật mã dựa trên lưới, dùng STARK 32-bit, dùng nhiều công nghệ khác nhau.
Câu hỏi là: Chúng ta có thể tối ưu hóa chữ ký tập hợp đến đâu? Đây là an ninh điểm-điểm, mọi người thường không suy nghĩ đủ về mạng ngang hàng. Đây là điều tôi muốn nhấn mạnh đặc biệt. Tôi nghĩ trong lĩnh vực mã hóa, người ta thường có xu hướng xây cấu trúc hoa mỹ trên mạng ngang hàng, rồi cho rằng mạng ngang hàng sẽ hoạt động ổn.
Ở đây tiềm ẩn nhiều rủi ro, đúng không? Tôi nghĩ những rủi ro này sẽ ngày càng phức tạp. Cách mạng ngang hàng hoạt động trong Bitcoin, cách nó hoạt động trong Bitcoin. Trong thập niên 2010, mỗi nút đều thấy mọi thứ. Dĩ nhiên bạn có thể thực hiện một số cuộc tấn công như tấn công nhật thực (eclipse), tấn công từ chối dịch vụ, và nhiều loại tấn công khác.
Nhưng khi bạn có một mạng rất đơn giản, và nhiệm vụ duy nhất của mạng là đảm bảo mọi người đều nhận được mọi thứ, thì vấn đề vẫn khá đơn giản. Vấn đề nằm ở chỗ khi Ethereum mở rộng quy mô, mạng ngang hàng ngày càng phức tạp. Mạng ngang hàng Ethereum hiện nay đã có 64 phân mảnh, đúng không?
Để thực hiện tập hợp chữ ký, để xử lý 30.000 chữ ký mỗi chu kỳ như hiện nay, chúng ta có một mạng ngang hàng được chia thành 64 mạng con khác nhau, mỗi nút chỉ thuộc một hoặc vài mạng. Trong lấy mẫu khả dụng dữ liệu (data availability sampling), kỹ thuật Ethereum dùng để cung cấp không gian dữ liệu cho khối nhằm đạt khả năng mở rộng, chỉ với hai dự án này, chi phí cho rollup đã rất thấp.
Việc này cũng phụ thuộc vào kiến trúc mạng ngang hàng phức tạp hơn. Ở đây, bạn thấy sơ đồ nút ngang hàng, trong thiết lập này, mỗi nút chỉ tải về 1/8 tổng dữ liệu. Vậy câu hỏi đặt ra: mạng như vậy thực sự an toàn không? Bạn có thể đảm bảo an toàn không? Bạn có thể nâng cao mức độ đảm bảo tối đa không? Làm sao để bảo vệ và nâng cao an toàn của mạng ngang hàng mà Ethereum đang phụ thuộc?
Về cơ bản, tôi nghĩ ở thời điểm này, chúng ta cần tập trung vào việc phát triển các giao thức có thể đạt đến giới hạn của công nghệ mã hóa. Công nghệ mã hóa của chúng ta đã mạnh hơn nhiều so với mười năm trước, nhưng vẫn có thể mạnh hơn nữa. Ở thời điểm này, tôi nghĩ chúng ta thực sự cần bắt đầu nghiên cứu giới hạn là gì, và làm sao để thực sự đạt được giới hạn đó.
Có hai lĩnh vực quan trọng như nhau. Một là tiếp tục nâng cao hiệu suất — chúng ta muốn chứng minh mọi thứ thời gian thực. Chúng ta muốn thấy một thế giới nơi trong các giao thức phi tập trung, mọi thông tin được truyền qua blog đều mặc định kèm theo một zk-SNARK để chứng minh rằng thông tin đó và mọi thứ nó dựa vào đều tuân thủ quy tắc giao thức.
Lĩnh vực tiên phong thứ hai là nâng cao an toàn. Về căn bản, là giảm thiểu khả năng xảy ra lỗi, để trong thế giới của chúng ta, các công nghệ thực tế mà các giao thức dựa vào có thể cực kỳ mạnh mẽ, cực kỳ đáng tin cậy, để mọi người có thể phụ thuộc vào nó tối đa. Dù các dự án có lỗi, nhưng mọi người sẽ không phụ thuộc vào công nghệ mã hóa, mà vẫn phụ thuộc vào con người.
Nhưng như chúng ta đã thấy nhiều lần, chữ ký đa phương (multisignature) cũng có thể bị hacker tấn công — có rất nhiều ví dụ như vậy, các dự án Layer2. Trong một hai dự án, tiền thực tế bị kiểm soát bởi một đa chữ ký, nhưng bằng cách nào đó, năm trong số chín dự án bị tấn công đồng thời, dẫn đến mất mát tài sản lớn. Nếu muốn vượt qua thế giới này, chúng ta cần tin vào những công nghệ thực sự có thể sử dụng, và thực sự thực thi quy tắc bằng mã hóa, chứ không phải tin vào một nhóm nhỏ người để đảm bảo quy tắc được tuân thủ.
Nhưng để làm được điều đó, mã nguồn phải đáng tin. Câu hỏi là: Chúng ta có thể làm cho mã nguồn đáng tin không? Mạng đáng tin không? Kinh tế học của các sản phẩm, các giao thức này đáng tin không? Tôi nghĩ đây là những thách thức cốt lõi, hy vọng chúng ta sẽ tiếp tục cùng nhau nỗ lực, cải tiến liên tục, xin cảm ơn.
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
@DethingsNews
