Bảo mật và Không tin cậy, giao thức ZK nên chọn cơ chế như thế nào?

Tiêu đề gốc: " Tóm tắt hàng tuần của iOSG ｜Bảo mật và Không tin cậy, cách chọn cơ chế của giao thức ZK 》

Nguồn gốc:  Liên doanh iOSG

Gần đây, zkSync và Polygon đã ra mắt zkEVM của riêng họ, tạo ra một làn sóng sốt trong ngành. Đồng thời, đã có rất nhiều cuộc thảo luận trong cộng đồng về tính bảo mật và phân cấp của zkEVM. IOSG đã tổ chức một sự kiện có chủ đề bảo mật (Stay SAFU, Security Day) trong thời gian ETHDenver vừa kết thúc. Chúng tôi đã may mắn được mời các dự án hàng đầu trong lĩnh vực bằng chứng không có kiến thức tham gia thảo luận. Họ đã chia sẻ giao thức bằng chứng không có kiến thức. Các nguyên tắc an toàn và giải pháp mới trong thiết kế cơ chế và xây dựng kỹ thuật cũng như những đánh đổi khác nhau trong quá trình thiết kế.

Sau đây là nội dung gốc được chia sẻ bởi các khách mời. Những người tham gia là:

Queenie Wu, Đối tác (người điều hành), IOSG Ventures;

Alex Gluchowski, đồng sáng lập, zkSync;

Ye Zhang, đồng sáng lập và trưởng nhóm nghiên cứu, Scroll;

Matt Finestone, COO của Taiko;

Mikhail Komarov, người sáng lập quỹ Nil;

Brian R, người sáng lập Risc0;  

 Q1: Zero- bằng chứng kiến thức nâng cao của bạn Hệ thống đang được xây dựng an toàn đến mức nào? Mặt khác, vấn đề bảo mật nào phát sinh từ việc triển khai bằng chứng không có kiến thức?

[Brian R]

Tôi là Brian Redford, Giám đốc điều hành của Risk Zero. Chúng tôi là nhà phát triển của Risk Zero zkVM, được xây dựng trên Kiến trúc vi mô Risk-V, để thực thi mã tùy ý trong hệ thống ZK. Chúng tôi cũng đang triển khai mạng Layer2 có tên Bonsai, mạng này có thể thực thi bất kỳ mã nào trong kịch bản ZK, có thể hiểu là máy gia tốc ZK. Về cách ZK tăng cường bảo mật, tôi đoán nó phụ thuộc vào tình huống ứng dụng cụ thể. Tất nhiên, việc có thể thực hiện tính toán và tạo ra bằng chứng có thể được xác minh ở bất kỳ đâu trên thế giới sẽ thay đổi hoàn toàn mô hình bảo mật blockchain. Bạn không còn cần phải thực hiện lại nhiều lần các phép tính giống nhau và sử dụng các cơ chế phức tạp (như cơ chế kinh tế) để đảm bảo an ninh cho toàn bộ hệ thống.

[Mikhail Komarov]

Tôi là người sáng lập Nil Mikhail Komarov. Chúng tôi cung cấp cơ sở hạ tầng cho các dự án ZK đang diễn ra, chẳng hạn như trình biên dịch zk-EVM. Trình biên dịch này có thể biên dịch các ngôn ngữ cấp cao thành các mạch để mọi phép tính được xác định bằng ngôn ngữ cấp cao có thể được chứng minh mà không cần thực hiện bất kỳ thao tác nào, chỉ là các mạch đơn giản. Ngoài ra, chúng tôi cũng giới thiệu khái niệm "Thị trường bằng chứng" để cung cấp thị trường đấu thầu phi tập trung cho các bên tham gia dự án muốn tạo bằng chứng zkSNARK/STARK. Mỗi nhà phát triển có thể gửi giá thầu cho bằng chứng không có kiến thức cần được tạo và sau đó chỉ cần gọi bằng chứng trong ứng dụng để nhận được dịch vụ được yêu cầu (ví dụ: zkRollup có thể sử dụng thị trường bằng chứng).

Về cơ bản, chúng tôi là cơ sở hạ tầng mà các nhà phát triển cần. Nó không làm cho chúng ta an toàn hơn một mình, nhưng nó làm cho chúng ta an toàn hơn về tổng thể. Như Brian đã nói, nó tăng cường bảo mật bằng cách loại bỏ giả định về độ tin cậy trong giao thức rằng nó sẽ hoạt động trong môi trường không tin cậy. Chìa khóa của nó là giảm bớt các giả định về niềm tin. Đây là cách nó tăng cường bảo mật. Tôi tin rằng nếu bằng chứng không có kiến thức được triển khai thì một số sự cố bảo mật xảy ra năm ngoái có thể tránh được.

[Matt Finestone]

Tôi là Matt đến từ Taiko, chúng tôi là một ZK Rollup tương thích với Ethereum. Chúng tôi cố gắng đạt được khả năng tương thích tối đa với Ethereum và EVM. Khi nói đến bảo mật, điều khiến chúng tôi trở nên độc đáo là sự phụ thuộc mạnh mẽ vào các khối xây dựng, khách hàng và mô hình hợp đồng thông minh Ethereum đã được thử nghiệm và chứng minh tốt. Như Mikhail đã nói, ZK giảm giả định về độ tin cậy hoặc chuyển nó sang cấp độ giao thức/bằng chứng. Thứ “cần được tin cậy” không còn là một số người có động lực nữa mà là toán học, các giao thức và ứng dụng được phát triển xung quanh các chứng minh toán học. Có rất nhiều điều cần cân nhắc về bảo mật đối với ZK Rollup, không chỉ ZK.

Tôi nghĩ chúng tôi tái sử dụng các phần bảo mật từ Ethereum nhiều nhất có thể để giữ an toàn. Theo thời gian và được thử nghiệm thực địa, ZK sẽ là một hệ thống rất mạnh mẽ.

[Ye Zhang]

Xin chào mọi người , tên tôi là Ye. Tôi làm việc tại Scroll. Trước tiên hãy để tôi giới thiệu ngắn gọn về Scroll. Scroll là giải pháp mở rộng quy mô của Ethereum. Nó rất tương thích với Ethereum, người dùng có thể tương tác với các ứng dụng và nhà phát triển có thể triển khai hợp đồng thông minh bằng cách chỉ cần sao chép và dán mã rồi di chuyển nó sang Scroll. Nó nhanh hơn và rẻ hơn Ethereum trong khi cung cấp thông lượng cao hơn và bảo mật chặt chẽ hơn. Chúng tôi sẽ phân cấp hệ thống chứng minh của mình (Mạng chứng minh phi tập trung) để ngăn chặn các điểm lỗi duy nhất trong hệ thống chứng minh. Đây là bước đầu tiên của chúng tôi hướng tới sự phân cấp, bởi vì ZK Rollup sẽ được phân cấp trong một thời gian dài sắp tới. Ngay cả khi bạn có nhiều niềm tin vào toán học, rất nhiều niềm tin vào mật mã, bạn vẫn có thể gặp phải điểm thất bại duy nhất này vì bạn đang dựa vào một nhà chứng minh nào đó.

Bước đầu tiên hướng tới phân cấp là phân cấp hệ thống chứng minh để làm cho nó đáng tin cậy hơn. Về tính bảo mật của ZK, tôi nghĩ những vị khách khác đã giới thiệu rằng ZK mang đến cho bạn những đặc tính có thể xác minh công khai rất mạnh mẽ. Về cơ bản, bất kỳ ai cũng có thể thực hiện tính toán và thực hiện bằng chứng, sau đó bất kỳ ai cũng có thể xác minh bằng chứng và nhận được những đảm bảo tương tự. Nếu bạn có hàng triệu nút, mọi người chỉ cần thực hiện lại thuật toán xác minh thay vì tính toán ban đầu, điều này cũng đạt được khả năng mở rộng của hệ thống. Đây là sức mạnh của công nghệ ZK. Đối với những vấn đề mà nó có thể gặp phải, nếu hệ thống của chúng ta hoàn toàn dựa vào các phép toán, nếu có một số lỗi, chẳng hạn như thiếu một số ràng buộc, thì có thể nguy hiểm. Đó là lý do tại sao chúng tôi thực hiện một số phương pháp để cải thiện tính bảo mật của mình. Ví dụ: chúng tôi áp dụng cách tiếp cận phát triển dựa vào cộng đồng. Ngay từ ngày đầu tiên, chúng tôi đã sử dụng nguồn mở tất cả các quy trình phát triển của mình và được cả Ethereum và cộng đồng của chúng tôi xem xét, đặt ra tiêu chuẩn cao hơn. Đây là cách chúng tôi giảm thiểu sự tin cậy và tăng cường bảo mật.

[Alex Gluchowski]

Tên tôi Alex Gluchowski là Giám đốc điều hành của Matter Labs, công ty đứng sau giao thức zkSync. Chúng tôi đang xây dựng Mạng kỷ nguyên zkSync, ZK Rollup tương thích với ZK EVM. Chúng tôi thực hiện một cách tiếp cận hơi khác với EVM tương đương với Rollup. Chúng tôi tin vào việc áp dụng cách tiếp cận thực tế, bắt đầu từ thứ gì đó tương thích để các nhà phát triển có thể dễ dàng cắm và chuyển các ứng dụng hiện có cũng như khởi chạy từ các công cụ hiện có. Tuy nhiên, môi trường ZK cuối cùng lại khác. Nếu bạn ràng buộc mình với công nghệ cũ, sẽ khó đạt được công suất tối đa của hệ thống ZK. Điều này rất quan trọng vì sứ mệnh của chúng tôi là mở rộng blockchain sang phạm vi thế giới thực, giới thiệu blockchain cho hàng tỷ người dùng tiếp theo và tạo ra một mạng Internet mới có giá trị. Nếu bạn nghĩ về hàng triệu hoặc thậm chí hàng tỷ người dùng, bạn thực sự muốn giảm chi phí vì khi tất cả hàng tỷ giao dịch đó cộng lại, chi phí sẽ trở nên rất đáng kể.

Điều này ảnh hưởng như thế nào đến cách chúng tôi tăng cường bảo mật? Đây là một câu hỏi rất thú vị. Khi bạn hỏi làm thế nào để cải thiện tính bảo mật hoặc bất kỳ yếu tố nào khác, bạn muốn so sánh các lựa chọn thay thế, phải không? Điểm chuẩn của tôi là gì? Các lựa chọn thay thế cho việc sử dụng ZK là gì? Các lựa chọn thay thế có thể là các công nghệ mở rộng quy mô khác có sẵn trước ZK Rollup, chẳng hạn như Optimistic Rollup, sidechains, Plasma, v.v. Những kế hoạch này đưa ra những giả định tin cậy mới. Nếu mục tiêu của chúng tôi là mở rộng quy mô lên 1 tỷ người dùng và sứ mệnh của chúng tôi không chỉ là mở rộng quy mô thông lượng mà còn mở rộng giá trị trong khi vẫn duy trì tính chất tự chủ, tự quản lý, không cần cấp phép và bản chất hoàn toàn không cần tin cậy của hệ thống, thì điều này chỉ có thể đạt được sử dụng ZK.

Câu 2: Khi so sánh các loại zkEVM khác nhau, chúng tôi thường tập trung vào khả năng mở rộng và khả năng tương thích của chúng (Vitalik đã thực hiện so sánh chi tiết về điều này: https:// /vitalik.ca/general /2022/08/04/zkevm.html), nếu chúng ta thêm một phương diện bảo mật vào đây, zkSync Era, Scroll và Taiko sẽ so sánh các rủi ro bảo mật tiềm ẩn khác nhau mà các thiết kế cơ chế khác nhau có thể mang lại như thế nào? ?

[Alex Gluchowski]

Như trước đây Như diễn giả đã đề cập, bạn cần phải ngầm tin tưởng nhiều thành phần của các hệ thống phức tạp này để đảm bảo an ninh, chẳng hạn như bạn tin tưởng mã do trình biên dịch tạo ra và bạn tin rằng nó đang thực thi logic mã mà bạn đặt trong trình biên dịch này. Tại sao bạn tin đó là Solidity? Nó không được xác định chính thức, vì vậy bạn chỉ cần tin tưởng trình biên dịch hoạt động chính xác từ phiên bản này sang phiên bản khác. Chúng tôi tin rằng đây là một vấn đề cần được giải quyết. Đó là lý do tại sao chúng tôi bắt đầu xây dựng một trình biên dịch dựa trên khung LLVM, hỗ trợ Solidity như một trong những giao diện người dùng và dựa trên khung hoàn thiện này. Có nhiều công cụ để phân tích tĩnh mã, kiểm tra bảo mật, v.v. và phía sau- cuối cùng là máy ảo zkVM của chúng tôi. Chúng tôi cũng có thể hỗ trợ các ngôn ngữ hoàn thiện hơn khác thực sự đã được sử dụng trong các môi trường an toàn khác, như Rust hoặc một số ngôn ngữ mới hơn đã bổ sung các cân nhắc về bảo mật, như Move, giúp tránh một số vấn đề về bảo mật, chẳng hạn như chi tiêu gấp đôi và những thứ tương tự. Nói chung, mặc dù nó phức tạp nhưng chúng ta phải giải quyết nó từ nhiều cấp độ khác nhau.

[Ye Zhang]

Tôi nghĩ vậy Nói về một số phương pháp khác nhau và nền tảng của chúng. Chúng tôi đang xây dựng giải pháp tương thích cấp độ EVM Bytecode. Về cơ bản chúng tôi có thể tương thích với EVM Bytecode. Điều này khác với cách zkSync được xây dựng và chúng tôi cũng tin rằng trình biên dịch không đáng tin cậy. Đây là lý do tại sao chúng tôi tin rằng trình biên dịch Solidity, mặc dù chưa hoàn thiện, nhưng đã tương đối trưởng thành trong bối cảnh blockchain. Trước đây chưa có ai sử dụng Solidity và LLVM. Chúng tôi tin rằng đó là một tiêu chuẩn tốt hơn vì nó đã được thử nghiệm trên thực tế và nhiều DeFi hợp đồng thông minh đã được các nhà phát triển Solidity thử nghiệm. Đó là lý do tại sao chúng tôi tin rằng việc tuân thủ các tiêu chuẩn của trình biên dịch này, tuân thủ các tiêu chuẩn của trình biên dịch Solidity, tuân thủ các định nghĩa của Sách vàng EVM là cách tốt nhất để đảm bảo an ninh hệ thống. Bởi vì về mặt mạch điện, chúng tôi không cần phải suy nghĩ về các vấn đề về trình biên dịch, chúng tôi không cần xây dựng trình biên dịch của riêng mình, chúng tôi chỉ cần sử dụng cơ sở hạ tầng hiện có và chứng minh rằng việc thực thi nó là chính xác.

Chúng tôi chỉ muốn đặt sự phức tạp của việc xây dựng hệ thống vào việc giải quyết tính tương thích của zkEVM ở cấp Bytecode, thay vì xây dựng trình biên dịch và chương trình phụ trợ hỗ trợ LLVM cùng một lúc. Chúng tôi không muốn Ngoài việc xây dựng zkEVM, bạn cũng cần xây dựng trình biên dịch. Một điều cần cân nhắc khác là chúng tôi chắc chắn quan tâm đến trải nghiệm của nhà phát triển. Layer2 được xây dựng để mở rộng EVM, vốn đã trở nên quá tải với số lượng lớn mã và ứng dụng Solidity. Chúng tôi muốn các nhà phát triển có thể di chuyển sang hệ thống của chúng tôi một cách liền mạch mà vẫn đảm bảo tính bảo mật. Đây là lý do tại sao hiện tại chúng tôi không có kế hoạch bổ sung thêm các tính năng thú vị hơn cho EVM.

Việc tuân theo tiêu chuẩn này có thể giúp Ethereum thực sự có khả năng mở rộng trong khi vẫn đảm bảo hiệu suất tối ưu và phân phối kịp thời hệ thống dựa trên nó. Đồng thời, chúng tôi cũng chính thức quảng bá các triển khai nguồn mở khác nhau trên Ethereum, bao gồm Type1 và Type2 zkEVM, bao gồm cả quyền riêng tư và mở rộng. Chúng tôi đã được xây dựng bằng nguồn mở ngay từ ngày đầu tiên. Chúng tôi rất tập trung vào sự phát triển và tiến hóa của Ethereum zkEVM, chúng tôi dẫn đầu một nửa quá trình phát triển của nó, chúng tôi là thành viên của nhóm, vì vậy chúng tôi biết chính xác sẽ mất bao lâu để toàn bộ hệ thống thực sự sẵn sàng. Đó là lý do tại sao chúng tôi áp dụng phương pháp này để chuẩn bị sản phẩm và tiếp cận cộng đồng, sau đó nghĩ về cách thúc đẩy mục tiêu cuối cùng của Ethereum.

[Matt Finestone]

Đây là Hai câu trả lời hay, giải pháp của Taiko và Scroll gần hơn và chúng tôi không giới thiệu trình biên dịch mới. Tôi thích những gì Alex đã nói, đâu là giải pháp thay thế cho bảo mật trong bối cảnh blockchain? Tôi nghĩ tất cả chúng ta đều có thể đồng ý rằng Ethereum có lẽ là tiêu chuẩn vàng. Chúng tôi tuân theo việc triển khai Sách vàng và tái sử dụng Ethereum thay vì điều chỉnh các thành phần của nó, ngay cả về các thành phần Ethereum khác ngoài EVM, cấu trúc lưu trữ dữ liệu, v.v., đã được chứng minh trong thực tế.

Tất nhiên, luôn có sự đánh đổi. Alex nói về một tỷ người dùng, chi phí cực thấp và khả năng mở rộng để duy trì giá trị. Chúng tôi có thể hy sinh nhiều hơn cho chi phí chứng minh, nhưng chúng tôi vẫn tuân thủ tiêu chuẩn EVM và tiêu chuẩn Ethereum đã được thử nghiệm trong chiến đấu. Chúng tôi cũng sẽ cân nhắc một số điều mà Ye Zhang đã nói về tính thực tế và việc gia nhập thị trường nhanh chóng.

Trong bối cảnh của ZK, có một số hướng không dễ thực hiện, chẳng hạn như một số hàm băm hoặc một số cấu trúc lưu trữ dữ liệu. Chúng tôi không thay đổi những điều này vì chúng tôi không chắc chúng sẽ hoạt động như thế nào, chẳng hạn như thay đổi Cây Merkel Patricia thành Cây Verkle, mặc dù điều này vốn đã nằm trong lộ trình của Ethereum. Chúng tôi tự tin hơn vào các thành phần đã được thử nghiệm và kiểm tra, và sự phức tạp của hệ thống không nằm ở việc cố gắng phát minh lại EVM của Ethereum và các thành phần khác, mà nằm ở cách ZK được triển khai đầy đủ tương thích với EVM. Việc này sẽ mất nhiều thời gian hơn để hoàn thành và có một số đánh đổi mà chúng tôi cần thực hiện lâu hơn Scroll để đạt được khả năng sử dụng. Về mặt bảo mật, lộ trình thực hiện của chúng ta sẽ yên tâm hơn.

[Mikhail Komarov]

Ethereum đã được thử nghiệm thực tế chiến đấu. Hãy tái sử dụng tất cả các hệ thống này và đưa ra ít giả định mới hơn. Nhưng có một số vấn đề bảo mật mà ít người thực sự quan tâm và chúng tôi mong muốn giải quyết chúng. Vấn đề đầu tiên là bạn phải tin tưởng vào trình biên dịch. Có một vấn đề khác, đó là, nếu bạn muốn đạt được khả năng tương thích EVM hoàn toàn, chẳng hạn như khả năng tương thích EVM Type1, thì bạn cần phải triển khai lại thủ công bất kỳ Opcode nào của EVM trong mạch, bằng cách tìm ra một biểu thức nhất định dưới dạng mạch, nó sẽ như thế nào giống như trên một miền nhất định? Đây là một quy trình thủ công, rất phức tạp và dễ xảy ra lỗi. Chúng tôi đã tự mình thực hiện việc này và làm hỏng mạch điện, vì vậy chúng tôi biết nó rất tệ.

Để không lặp lại những vấn đề này và để bất kỳ ai mắc phải những sai lầm này, chúng tôi đang nỗ lực biên soạn các mạch bằng cách cho phép mọi người triển khai EVM đã được thử nghiệm thực tế, để loại bỏ giả định bảo mật này bằng cách triển khai lại tất cả OpCode theo cách thủ công. Mục tiêu của chúng tôi là đưa ra các giả định an toàn tối thiểu bằng cách biên dịch nó bằng trình biên dịch LLVM thay vì triển khai lại theo cách thủ công. Đây là một giả định bảo mật khác cần được loại bỏ và chúng tôi sẽ giải quyết nó cho zkEVM.

[Brian R]

Bạn có thể Chạy geth trên hệ thống như RiscV sẽ giải quyết được vấn đề mà Mikhail đề cập. Thực ra chúng tôi vừa thêm hỗ trợ cho Go. Chúng tôi đã xây dựng và thiết kế RiscZero VM, đồng thời chúng tôi chọn tập lệnh RiscV một phần vì nó được xác định chính thức và rất nhẹ. Đường bao an toàn của các mạch RiscV đã được chỉ định và công việc đáng kể đã được thực hiện để kết hợp các phương pháp xác minh chính thức nhằm chứng minh rằng việc triển khai tuân thủ đặc tả RiscV. Chúng tôi tập trung vào việc mã hóa chính xác trong hệ thống đơn giản này và sau đó chạy EVM trên nó thực sự hoạt động. Tất nhiên, có một hình phạt về hiệu suất với cách tiếp cận này. Ví dụ: mất khoảng 1 phút để chuyển ERC20Token.

Q3: Như Alex vừa đề cập, có thể nâng cấp hoặc lựa chọn giải pháp khác cho bất kỳ phần nào của hệ thống. Vì vậy, làm thế nào để bạn đảm bảo khả năng mở rộng hệ thống và thực hiện điều đó một cách rất an toàn?

[Brian R]

Có, tôi nghĩ khả năng nâng cấp là một chủ đề rất quan trọng trong ZK. Theo quan điểm của chúng tôi, nếu không triển khai mạng và có nhiều giá trị tài chính đằng sau nó, chúng tôi đã dành rất nhiều thời gian để đảm bảo rằng chúng tôi đang xây dựng các tóm tắt ngăn xếp công nghệ phù hợp. Chúng ta có thể chuyển đổi hàm băm, chuyển đổi trường hữu hạn và hệ thống chứng minh hoặc thêm các công nghệ mới, chẳng hạn như PLONK, vào ngăn xếp công nghệ. Đây là một lý do khác khiến chúng tôi chọn RiscV làm "bộ lệnh" được hỗ trợ chính, vì bản thân nó là một hệ thống trừu tượng rất rõ ràng. Vì vậy, bạn có thể thay thế bất cứ điều gì bạn muốn. LLVM rõ ràng có những đặc điểm rất giống nhau.

[Matt Finestone]

Có, nâng cấp là một Đó là một chủ đề lớn, chúng ta có thể coi nó như một vấn đề của các hệ thống không tin cậy. Có thể có những lỗ hổng trong quá trình triển khai và triển khai hệ thống, người dùng sẽ gặp rủi ro hoặc họ có thể phải tin tưởng vào người xây dựng hệ thống hoặc một số người tham gia, những người có thể lợi dụng hệ thống, v.v. Leo thang là tìm kiếm sự cân bằng giữa bảo mật và sự không tin cậy ở một số cấp độ. Khi niềm tin của bạn vào hệ thống tăng lên, bạn có thể loại bỏ một số tác nhân đáng tin cậy này. Ở đây, chúng ta nên hết sức cảnh giác với một số tác nhân đáng tin cậy vì mục đích của việc làm này là để loại bỏ những tác nhân này. Đối với những hệ thống rất phức tạp này, tốt nhất nên can thiệp sớm. Tôi nghĩ Alex và nhóm Matter Labs đã cung cấp một số ví dụ tham khảo tuyệt vời về vấn đề này. Họ có một ủy ban an toàn tốt và cơ chế trì hoãn thời gian.

Vậy đâu là nhịp điệu chính xác cho việc nâng cấp? Đây là một câu hỏi rất quan trọng và tôi không biết liệu có nhiều người dùng cảm thấy thoải mái hơn với một hệ thống hoàn toàn không cần sự tin cậy hay không, bởi vì những hệ thống như vậy thường rất phức tạp, giới thiệu nhiều điều mới hoặc tin tưởng những người tham gia có thiện chí này. Đây là một vấn đề rất con người và tất nhiên có một số giải pháp kỹ thuật, chẳng hạn như nhiều bằng chứng có thể là một lựa chọn tốt. Tôi nghĩ chúng ta có thể sử dụng lại một số thiết kế từ các thành phần tương tự như Optimism. Nếu bằng chứng hợp lệ của chúng tôi có vấn đề thì việc sử dụng lại việc triển khai Tổng hợp lạc quan sẽ giúp việc xây dựng hệ thống chống gian lận để hệ thống hoạt động trong môi trường tương đương Ethereum trở nên dễ dàng hơn. Bạn có thể kết hợp các bằng chứng gian lận và bằng chứng hợp lệ, và nếu có bất kỳ sự phản đối nào thì khả năng mở rộng hoặc một số loại kế hoạch quản trị có thể ghi đè lên nó.

[Mikhail Komarov]

Hãy để tôi Hãy cùng bàn về chuyện này. Tôi vừa dành chút thời gian suy nghĩ về điều này. Tôi lo lắng là tôi không hiểu câu hỏi vì tôi đang muốn nói vấn đề nâng cấp ở đâu? Chỉ cần xây dựng lại mạch. Vậy chính xác thì vấn đề nâng cấp là gì?

[Ye Zhang]

Từ chúng tôi Từ góc độ, trước hết, bạn chắc chắn không thể biên dịch một mạch mới vì nó sẽ ảnh hưởng đến các khóa chứng thực, khóa xác minh và nhiều hợp đồng thông minh trên chuỗi của bạn, vì vậy bạn chắc chắn không thể làm điều đó thường xuyên. Chúng tôi đang xem xét nhiều phương pháp chứng minh và bổ sung các cơ chế như xác minh kép. Có nhiều cách để giải quyết vấn đề này, ngoại trừ như Matt đã đề cập, chúng tôi không xem xét việc tích hợp trực tiếp với bằng chứng gian lận của Optimistic vì nó sẽ khiến thời gian xác nhận cuối cùng lâu hơn. Chúng tôi đang khám phá một số phương pháp tiếp cận khác và sẽ sớm có một số đề xuất trong Nghiên cứu Ethereum về cách bổ sung một số đảm bảo bổ sung.

Ví dụ: Justin Drake đã đề xuất sử dụng Intel SGX (môi trường TEE) như một số đảm bảo bổ sung, bổ sung nghiêm ngặt các đảm bảo an ninh. Ngoài ra, có thể có một số phương pháp quản trị khác và chúng tôi cho rằng ủy ban an toàn và thời gian trì hoãn là những phương pháp tốt. Chúng tôi cũng đang suy nghĩ về vấn đề này. Đó là một sự đánh đổi và tôi tin rằng hầu hết các Bản tổng hợp sẽ vẫn mất nhiều thời gian hơn để thực sự khắc phục được vấn đề về khả năng nâng cấp này, vì việc nâng cấp hệ thống là một việc lâu dài. Chúng tôi đang quan tâm và nghiên cứu kỹ vấn đề này.

[Alex Gluchowski]

Tôi có thể Để cung cấp một số thông tin cơ bản, tại sao khả năng nâng cấp lại là một vấn đề quan trọng. Ví dụ, chương trình nào chạy trên desktop máy tính thì bạn chỉ cần tải phiên bản mới về và cài đặt thôi phải không? Có gì sai khi nâng cấp? Vấn đề là trong bối cảnh blockchain, chúng ta đang cố gắng xây dựng các hệ thống không cần sự tin cậy, nhưng trong một số trường hợp, nhu cầu nâng cấp có thể làm suy yếu niềm tin đó. Đối với Layer1, không có vấn đề như vậy. Nếu bạn muốn nâng cấp Ethereum, bạn chỉ cần tải xuống ứng dụng khách mới, cài đặt nó và mọi người sẽ điều phối fork.

Sau đó, chúng tôi sắp xếp một nhánh, đặt ngày và một nhánh ở một số khối nhất định, để bất kỳ ai không thích nâng cấp này có thể ở lại nhánh cũ với một phiên bản cũ. Con đường mở rộng này hoàn toàn không cần sự tin cậy. Nó không khiến bạn phải phụ thuộc vào bất kỳ đa số trung thực nào hoặc bất kỳ người tham gia đáng tin cậy nào.

Sự cố xảy ra trong bối cảnh của Layer2. Nếu chúng ta xây dựng Rollup thì Rollup phụ thuộc vào hợp đồng thông minh của Layer1. Hợp đồng thông minh này có thể không thay đổi được, với một số chức năng cố định và khóa xác minh cho một số mạch nhất định đã được tích hợp sẵn, thì vấn đề là nếu có lỗi thì bạn không thể làm gì được. Vậy bạn sẽ làm gì nếu gặp phải một lỗi hoặc nếu bạn muốn sửa nó?

Chúng tôi đã tiết lộ một lỗ hổng trong zkSync 1.0 (zkSync Lite) với khóa thời gian có thể nâng cấp để nhóm có thể đề xuất nâng cấp cho các phiên bản mới. Sau đó, nếu người dùng không thích phiên bản mới, tất cả người dùng có vài tuần để xóa tài sản khỏi Layer1. Chúng tôi có cơ chế Trustless để thực hiện thoát. Nhưng bị buộc phải khóa thời gian này, chúng tôi không thể sửa chữa được nên chúng tôi đã đưa ra một thỏa hiệp và giới thiệu cái mà chúng tôi gọi là Hội đồng Bảo an, một ủy ban độc lập. Chúng tôi đã mời khoảng 15 thành viên nổi tiếng của cộng đồng Ethereum từ các cộng đồng khác nhau và các dự án khác nhau tham gia cùng chúng tôi.

Nhóm không kiểm soát hợp đồng và chỉ có thể đề xuất phương án nâng cấp, Hội đồng Bảo an đưa ra quyết định và có thể quyết định đẩy nhanh việc nâng cấp. Nhưng đây vẫn không phải là phương án tốt nhất, vì về mặt lý thuyết vẫn có một nhóm người có thể cài đặt phiên bản độc hại ngay lập tức trong giai đoạn này. Có thể họ không muốn làm nhưng cũng có thể bị một số người tham gia ép buộc, và chúng ta không thể loại trừ khả năng đó. Vì vậy, nếu chúng ta muốn tận dụng tối đa các bằng chứng không có kiến thức và chỉ dựa vào toán học và mã nguồn mở thay vì bất kỳ người xác minh, bên đáng tin cậy nào, v.v., thì cuối cùng chúng ta sẽ đạt được một cơ chế hoàn toàn Không cần tin cậy.

Chúng tôi hiện đang suy nghĩ về một giải pháp tốt hơn. Nhóm sẽ đề xuất đề xuất nâng cấp có giới hạn thời gian. Hội đồng Bảo an có thể can thiệp và đề xuất đóng băng hợp đồng thông minh, và sau đó tiếp tục trên Layer 1. Soft fork. Vì vậy, điều này đòi hỏi sự phối hợp với Layer1, yêu cầu giao thức Layer2 đã đạt đến một quy mô nhất định và đủ quan trọng để cộng đồng thực sự phân nhánh, cài đặt các phiên bản mới, v.v. Bởi vì Layer1 không thể thực hiện điều này cho mọi giao thức nhỏ nên nó phải là thứ gì đó quan trọng như thứ ở cấp độ hệ thống trên Ethereum.

Đây là cơ chế tốt nhất mà chúng tôi hiện có để nâng cao giải pháp không cần tin cậy, có thể mở rộng nhằm bảo vệ chúng tôi khỏi các lỗ hổng nghiêm trọng ở lớp 1. Nhưng điều này vẫn sẽ gây ra một số vấn đề về tính kịp thời. Nếu những vấn đề như vậy phát sinh, giao thức sẽ bị tạm dừng trong một khoảng thời gian. Hãy tưởng tượng rằng chúng ta đã chuyển từ Visa và PayPal sang sử dụng các khoản Rollup lớn như vậy để thanh toán trên blockchain và đột nhiên tài sản của người dùng bị đóng băng, không có ai sẵn sàng thanh toán, việc yêu cầu chúng tôi phối hợp nâng cấp trong vài ngày là một vấn đề lớn. Hiện tại chúng tôi không có giải pháp nào tốt hơn và cũng chưa thấy giải pháp nào tốt hơn. Nếu bạn có ý tưởng, vui lòng liên hệ với chúng tôi và cùng thảo luận thêm.

Q4: Có một từ khóa được nhắc đến nhiều lần, đó là "Trustless". Như chúng ta đã biết, thành phần quan trọng nhất của hệ thống hiện tại vẫn là tập trung. Chúng ta sẽ phải đối mặt với những thách thức bảo mật nào trong quá trình phát triển từ tập trung hóa sang phân quyền?

[Alex Gluchowski]

Tôi nghĩ vậy Điều này (Trustless) sẽ tăng cường bảo mật. Điều này sẽ cung cấp cho chúng tôi một yếu tố bảo vệ bổ sung. Đầu tiên, ZK Rollup phải cung cấp bằng chứng hợp lệ cho từng khối, nhưng nó có thể có vấn đề, chẳng hạn như có thể chúng ta quên một số ràng buộc. Ngoài ra, chúng tôi cũng cần cung cấp chữ ký thông qua cơ chế đồng thuận bằng chứng cổ phần, đây là một lớp bảo vệ bổ sung. Bởi vì để thỏa hiệp hệ thống, kẻ tấn công độc hại trước tiên phải tìm ra lỗ hổng, sau đó phải làm việc với phần lớn những người xác thực này để làm điều ác.

Khả năng này tương đối nhỏ, vì kẻ tấn công đã là bên kiểm soát trên blockchain này hoặc phải mua một số lượng lớn Token. Điều này cho chúng tôi đủ thời gian và những người khác cũng có thể phát hiện ra lỗ hổng tương tự. Và gửi nó cho Immunefi hoặc nơi khác để nhóm có thể khắc phục. Hoặc có thể chúng tôi sẽ chạy một số honeypot cùng lúc, hoàn toàn mở cho bất kỳ ai hack và nhận phần thưởng. Vì vậy, về tổng thể, điều này cung cấp hai yếu tố bảo vệ cho toàn bộ hệ thống. Và, chúng ta có thể thêm nhiều yếu tố hơn nữa.

Cho đến nay, tôi sẽ không tin rằng ZK Rollup được tuyên bố là hoàn toàn không cần sự tin cậy là an toàn. Đối với tôi, điều đó sẽ cực kỳ rủi ro. Tôi sẽ không đặt số tiền lớn hơn vào ZK Rollup như thế này với số tiền mà tôi có thể đủ khả năng để mất.

Ví dụ tôi thích nhất là sự cố Boeing 737 Max. Nguyên nhân của vụ tai nạn này không phải là vấn đề phần mềm mà họ đang cố gắng chuyển hướng sự chú ý của công chúng mà là do họ dựa vào một cảm biến duy nhất trên máy bay, đó là hành vi hoàn toàn vô trách nhiệm. Ngành hàng không có lịch sử phát triển lâu đời và trải qua nhiều lần lặp lại công nghệ, trong ngành có sự đồng thuận là không thể chỉ dựa vào một hệ thống duy nhất. Nhưng vì họ đã hy sinh thiết kế hệ thống an toàn vì nhiều lý do khác nhau (chẳng hạn như chi phí, thời gian giao hàng, v.v.) trong quá trình sản xuất Boeing 737 Max nên cuối cùng đã dẫn đến tai nạn. Vì vậy, chúng ta luôn mong muốn có ít nhất hai yếu tố an toàn hoàn toàn độc lập để giảm xác suất xảy ra sự cố.

[Ye Zhang]

Chúng tôi ủng hộ Hãy suy nghĩ về lộ trình phi tập trung của ZK Rollup từ góc độ dài hạn. Tất cả chúng tôi đều có ý tưởng riêng về việc nên phân cấp Sequencer hay Prover trước, hoặc thậm chí cách xác định tính phân cấp của ZK Rollup. Tôi nghĩ cuối cùng chúng tôi sẽ phân cấp cả Sequencer và Prover. Nhưng chúng tôi có những ưu tiên hơi khác nhau và trước tiên chúng tôi muốn phân quyền cho Prover. An ninh chắc chắn là một trong những lý do lớn. Nếu Sequencer được phân cấp trước, trước khi zkEVM trở nên rất trưởng thành và mạnh mẽ, nếu ai đó thực sự tìm thấy một số sơ hở và gửi bằng chứng sai, thì có khả năng nhất định là nó sẽ được Sequencer chấp nhận và một khối sẽ được tạo ra, gây thiệt hại cho hệ thống .

Do đó, chúng tôi sẽ giữ Bộ sắp xếp tập trung trước tiên. Bởi vì zkEVM có thể có lỗ hổng vì đây là một hệ thống rất phức tạp. Do đó, chúng tôi hy vọng rằng ít nhất trong giai đoạn đầu, chúng tôi có thể kiểm soát thứ tự tập trung và ít nhất đảm bảo việc tạo khối chính xác và hiệu quả.

Một lý do khác để phân cấp Prover trước tiên là có nhiều công ty phần cứng đang tìm cách làm cho zkEVM hiệu quả hơn. Nếu chúng tôi cam kết thực hiện phương pháp phân cấp Prover này, họ sẽ tham gia vào việc tối ưu hóa mã của hệ thống. Tất cả chúng ta đều biết rằng ZK ASIC có thể mất hơn một năm để ra mắt và nếu chúng ta phân quyền cho Prover trước, họ sẽ có nhiều động lực hơn để xây dựng hệ thống của chúng tôi và làm cho nó hiệu quả hơn. Việc phân cấp Sequencer là điều chúng tôi dự định thực hiện sau này.

Ở đây có một yếu tố phức tạp hơn cần xem xét, nếu Prover và Sequencer được phân vào hai nhóm khác nhau thì kế hoạch khuyến khích cần phải được thiết kế rất cẩn thận. Làm thế nào chúng ta có thể đưa ra tỷ lệ Phần thưởng dành cho một bên có đủ hợp lý và cân bằng giữa động cơ của cả hai bên?

Ngoài ra, chúng tôi còn có một số biện pháp an ninh khác. Ví dụ: cách chúng tôi xây dựng nó là nguồn mở, chúng tôi đang thực hiện một số kiểm tra bảo mật nội bộ, không chỉ kiểm tra bên ngoài. Chúng tôi có một đội ngũ an ninh rất mạnh. Chúng tôi cung cấp nhiều khoản tài trợ tài chính khác nhau để khuyến khích nhiều người hơn tham gia xây dựng các giải pháp bảo mật, chẳng hạn như các công cụ như xác minh chính thức. Nhóm của chúng tôi cũng đã tìm thấy các lỗ hổng trong mạch Consensys ZKEVM và Aztec. Chúng tôi đang cố gắng cải thiện tính bảo mật của toàn bộ hệ sinh thái.

 [Matt Finestone]

Taiko có thể phải đối mặt với thử thách này sớm hơn. Mặc dù mọi người đều có một mức độ phân quyền nhất định, nhưng chúng tôi thực sự đang có kế hoạch duy trì cách tiếp cận tương tự như Ethereum, bao gồm EVM, lịch trình Gas và cây trạng thái, v.v., đồng thời tính đến Ethos và sự phân cấp khác (chúng tôi gọi nó là) Sequencer Người đề xuất và người chứng minh. Trong mạng thử nghiệm đầu tiên cách đây vài tháng, khoảng 2.000 cá nhân hoặc địa chỉ duy nhất đã đề xuất chặn mà không được phép. Mặc dù có thể có một số khối độc hại nhưng đây cũng là lời hứa về sự phân quyền. Tôi nghĩ đó không phải là sự phân quyền lũy tiến, có thể đó là sự tăng dần tính hiệu quả, bởi vì bạn phải từ bỏ một số hiệu quả. Người đề xuất có thể tạo cùng một khối, dẫn đến một số giao dịch dư thừa và cũng phải trả một số không gian khối có giá trị trong ETH cho Lớp1. Một số người sẽ được hoàn tiền, những người khác sẽ bỏ qua.

Việc chúng tôi đạt được sự phân quyền ngay lập tức trong mạng thử nghiệm tiếp theo sắp tới là không thực tế. Những người chứng minh không được phép sẽ gặp khó khăn hơn trong môi trường testnet vì có các cuộc tấn công phù thủy, mọi người sẽ lấp đầy các khối được đề xuất bằng thư rác và Prover phải tiêu tốn tài nguyên máy tính thực sự để chứng minh chúng, nhưng không có thu nhập thực sự.

Do đó, chúng tôi sẽ sử dụng Người đề xuất được cấp phép để cho phép bất kỳ Nhà cung cấp phi tập trung nào gửi khối và nhận phần thưởng tương ứng. Điều này rất quan trọng. Ngoài ra, nếu hệ thống bị lỗi và Prover gửi bằng chứng hợp lệ và bằng chứng không nhất quán được gửi, hợp đồng thông minh có thể biết và tạm dừng. Liệu nó có nhận ra lý do tại sao có hai bằng chứng xác thực chính xác trên các khối khác nhau không? Khi điều này xảy ra, nó sẽ bị tạm dừng ngay lập tức, điều này sẽ gây ra sự chậm trễ về thời gian. Như Alex đã nói, hiện tại chúng tôi không thể cảm thấy thoải mái với việc triển khai hoàn toàn không cần sự cho phép, không cần sự tin cậy và chúng tôi đang cố gắng đạt được sự cân bằng.

[Mikhail Komarov]

Chúng tôi đã cân nhắc điều đó ngay từ đầu đã giải quyết được vấn đề này Giải pháp ban đầu của một số người là cách tiếp cận từ trên xuống, chẳng hạn như quyết định tạo một Bản tổng hợp, sau đó nghĩ đến thứ tự phân cấp, chẳng hạn như phân cấp Bộ sắp xếp trước. Sau đó phân cấp Prover, liên kết theo liên kết. Ngược lại, chúng tôi áp dụng một cách tiếp cận khác, đó là tiếp cận vấn đề từ dưới lên.

Lần đầu tiên chúng tôi xây dựng một mạng Prover phi tập trung để tập hợp sức mạnh tính toán mà không được phép. Sau đó, chúng tôi đã cố gắng thêm Sequencer trên cơ sở mạng Prover, vì Sequencer phải được tích hợp chặt chẽ với mạng Prover, đặc biệt là với mạng Prover phi tập trung trưởng thành. Điều này liên quan đến nhu cầu trả thêm phí chứng minh, độ phức tạp trong giao tiếp và các vấn đề khác, vì vậy Sequencer phải được tích hợp chặt chẽ với mạng Prover để đảm bảo tính hiệu quả của nó. Hệ thống chúng tôi phát triển có thể đóng vai trò là cơ sở hạ tầng cơ bản của ZK Rollup.

Để đảm bảo rằng tất cả việc tạo bằng chứng đều có cơ chế khuyến khích để tăng tốc độ hoàn thành, cải thiện chất lượng và duy trì tính bảo mật, chúng tôi đã giới thiệu một thị trường bằng chứng. của mọi bằng chứng. Đồng thời, chúng tôi giữ cho hệ thống được phân quyền và không cần cấp phép. Cách tiếp cận này giải quyết vấn đề từ dưới lên thay vì từ trên xuống.

[Brian R]

Tôi nghĩ vậy Cách tiếp cận chúng tôi thực hiện rất khác so với các mạng khác. Tương tự như thị trường bằng chứng mà nhóm Nil đang xây dựng, nhưng chúng tôi áp dụng cách tiếp cận không đáng tin cậy hơn. Hiện tại chúng tôi không tập trung vào vấn đề Trình tự mà tập trung vào hệ thống chứng minh để nó có thể thực hiện các hoạt động khác nhau một cách mạnh mẽ hơn. Cách tiếp cận này đơn giản hóa rất nhiều sự phức tạp và giúp đưa máy tính tốt nhất ra thị trường nhanh nhất có thể.

Chúng tôi muốn hạ thấp rào cản gia nhập đối với các nhà phát triển và cho phép họ xây dựng bất kỳ ứng dụng nào họ muốn trên Ethereum hoặc bất kỳ hệ thống nào và có được sự phân quyền này. Lớp điện toán cơ bản không sử dụng - Chứng minh kiến thức để đảm bảo tính đúng đắn của phép tính.

Câu 5. Khán giả: Trong Algorand, A kỹ thuật gọi là State Painting nổi lên. Ý tưởng cơ bản của nó là trích xuất trạng thái từ một blockchain đồng thuận và "Sơn" nó sang một blockchain đồng thuận khác. Công nghệ này giống như một giải pháp chuỗi chéo hơn và nó cũng sử dụng giải pháp chứng minh không có kiến thức. Trong Layer2, sự đồng thuận của hệ thống thực sự phụ thuộc vào sự đồng thuận của Layer1. Điều này có làm giảm tính bảo mật của Layer2 không?

[Alex Gluchowski]

Trong quá trình triển khai ZK Rollups, luồng tài sản giữa Lớp 1 và Lớp 2 hoàn toàn được thực hiện không cần tin cậy và Layer2 kế thừa hoàn toàn tính bảo mật của Layer1. Về việc chuyển giao tài sản giữa Lớp 2, nếu bạn đi qua cầu nối gốc của Ethereum Lớp 1 thì cũng hoàn toàn không cần tin cậy. Tuy nhiên, nếu Lớp 1 không được thông qua, tính bảo mật của nó phụ thuộc vào phương thức chuỗi chéo nào được sử dụng để đạt được cầu nối.

Trong zkSync, chúng tôi đang triển khai một giải pháp có tên Hyperchain. Cụ thể, chúng tôi sẽ xây dựng nhiều chuỗi được cung cấp bởi cùng một mạch vẫn được kết nối trên Ethereum. Hyperchain sẽ cung cấp các giao dịch miễn phí, hoàn toàn không cần sự tin cậy, rất rẻ từ bất kỳ chuỗi nào đến bất kỳ chuỗi nào khác. Điều này rất quan trọng khi chúng ta đang nói về việc đưa hàng trăm triệu hoặc thậm chí hàng tỷ người dùng vào blockchain.

Trong tương lai, chúng ta sẽ không thể có hàng nghìn tỷ giao dịch được thực hiện trên một hệ thống hoặc sự đồng thuận duy nhất. Chúng sẽ phải chạy trên nhiều hệ thống đồng thuận khác nhau, chẳng hạn như sharding, chuỗi ứng dụng độc lập, v.v. Nhưng đồng thời, chúng ta cần đảm bảo chi phí kết nối và liên lạc thấp giữa các chuỗi khác nhau này.

Ví dụ: Giống như chúng tôi sử dụng các hệ thống email khác nhau hiện nay, người dùng có thể dễ dàng hoàn thành việc liên lạc giữa các hệ thống email khác nhau. Đây là những gì chúng tôi hy vọng đạt được với Hyperchain. Ngoài việc kế thừa hoàn hảo tính năng bảo mật Lớp 1, giao tiếp xuyên chuỗi hiệu quả và không cần tin cậy, Hyperchain còn có thể đạt được chi phí sử dụng cực thấp thông qua các bằng chứng đệ quy.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia