Vitalik: Những ý tưởng mới để nâng cao hiệu quả - kiến ​​trúc dán và đồng xử lý

Tiêu đề gốc: Kiến trúc keo và bộ đồng xử lý

Tác giả: Vitalik, người sáng lập Ethereum; Người biên dịch: Deng Tong, Golden Finance

Đặc biệt cảm ơn Justin Drake, Georgios Konstantopoulos, Andrej Karpathy , Michael Gao, Tarun Chitra và nhiều cộng tác viên Flashbots khác nhau để đưa ra phản hồi và nhận xét.

Nếu bạn phân tích ở mức độ vừa phải bất kỳ phép tính tốn nhiều tài nguyên nào đang diễn ra trong thế giới hiện đại, bạn sẽ thấy một đặc điểm hết lần này đến lần khác là phép tính có thể được chia thành hai phần:

Hai dạng tính toán này được xử lý tốt nhất theo những cách khác nhau: dạng thứ nhất có kiến ​​trúc có thể kém hiệu quả hơn nhưng cần phải rất chung chung; sẽ rất hiệu quả.

Một số ví dụ về cách tiếp cận khác biệt này trong thực tế là gì?

Trước tiên, chúng ta hãy xem môi trường mà tôi quen thuộc nhất: Máy ảo Ethereum (EVM). Đây là dấu vết gỡ lỗi geth của một giao dịch Ethereum gần đây mà tôi đã thực hiện: Cập nhật hàm băm IPFS của blog của tôi trên ENS. Giao dịch đã tiêu thụ tổng cộng 46924 gas, có thể được phân loại như sau:

• Chi phí cơ bản : 21.000

• Dữ liệu cuộc gọi: 1.556

• Thực thi EVM: 24.368

• Mã hoạt động SLOAD: 6.400

• SSTORE Opcode: 10.100

• LOG opcode: 2.149

• Khác: 6.719



Dấu vết EVM của các bản cập nhật hàm băm ENS. Cột áp chót là lượng gas tiêu thụ.

Bài học của câu chuyện là thế này: phần lớn việc thực thi (khoảng 73% nếu bạn chỉ nhìn vào EVM, khoảng 85% nếu bạn bao gồm phần chi phí cơ bản của tính toán) được tập trung cực kỳ Trong số ít các hoạt động đắt tiền có cấu trúc: đọc và ghi lưu trữ, ghi nhật ký và mã hóa (chi phí cơ bản bao gồm 3000 để xác minh chữ ký thanh toán, EVM cũng bao gồm 272 để băm thanh toán). Phần còn lại của quá trình thực thi là "logic nghiệp vụ": hoán đổi các bit của calldata để trích xuất ID của bản ghi mà tôi đang cố gắng đặt và hàm băm mà tôi đang đặt, v.v. Trong chuyển mã thông báo, điều này sẽ bao gồm việc cộng và trừ số dư, trong các ứng dụng nâng cao hơn, điều này có thể bao gồm xoay vòng, v.v.

Trong EVM, hai hình thức thực thi này được xử lý khác nhau. Logic nghiệp vụ cấp cao được viết bằng ngôn ngữ cấp cao hơn, thường là Solidity, biên dịch sang EVM. Công việc tốn kém vẫn được kích hoạt bởi các mã EVM (SLOAD, v.v.), nhưng hơn 99% tính toán thực tế được thực hiện trong các mô-đun chuyên dụng được viết trực tiếp bên trong mã máy khách (hoặc thậm chí cả thư viện).

Để nâng cao hiểu biết của chúng ta về mẫu này, hãy khám phá nó trong một bối cảnh khác: Mã AI được viết bằng python sử dụng torch.



Chuyển tiếp một khối của mô hình máy biến áp

Chúng ta thấy gì ở đây? Chúng tôi đã thấy một lượng tương đối nhỏ "logic nghiệp vụ" được viết bằng Python, mô tả cấu trúc của các hoạt động đang được thực hiện. Trong một ứng dụng thực tế, sẽ có một loại logic nghiệp vụ khác xác định các chi tiết như cách lấy đầu vào và những việc cần làm với đầu ra. Tuy nhiên, nếu chúng ta đi sâu vào từng thao tác riêng lẻ (các bước riêng lẻ bên trong self.norm, torch.cat, +, *, self.attn...), chúng ta sẽ thấy các phép tính được vector hóa: các thao tác tương tự được tính toán ồ ạt theo giá trị song song . Tương tự như ví dụ đầu tiên, một phần nhỏ các phép tính được sử dụng cho logic nghiệp vụ và phần lớn các phép tính được sử dụng để thực hiện các phép toán vectơ và ma trận có cấu trúc lớn - trên thực tế, hầu hết chúng chỉ là phép nhân ma trận.

Giống như trong ví dụ EVM, hai loại công việc này được xử lý theo hai cách khác nhau. Mã logic nghiệp vụ cấp cao được viết bằng Python, một ngôn ngữ rất linh hoạt và linh hoạt, nhưng cũng rất chậm và chúng tôi đơn giản chấp nhận sự kém hiệu quả vì nó chỉ liên quan đến một phần nhỏ trong tổng chi phí tính toán. Trong khi đó, các thao tác chuyên sâu được viết bằng mã được tối ưu hóa cao, thường là mã CUDA chạy trên GPU. Càng ngày chúng ta càng bắt đầu thấy suy luận LLM được thực hiện trên ASIC.

Mật mã lập trình hiện đại, chẳng hạn như SNARK, lại tuân theo mô hình tương tự ở hai cấp độ. Đầu tiên, câu tục ngữ có thể được viết bằng ngôn ngữ cấp cao, trong đó công việc nặng nhọc được thực hiện thông qua các hoạt động được vector hóa, giống như trong ví dụ AI ở trên. Mã STARK tròn tôi có ở đây chứng minh điều này. Thứ hai, bản thân các chương trình được thực thi bên trong mật mã có thể được viết theo cách phân chia giữa logic kinh doanh chung và công việc tốn kém có cấu trúc cao.

Để hiểu cách thức hoạt động của điều này, chúng ta có thể xem xét một trong những xu hướng mới nhất được STARK thể hiện. Để linh hoạt và dễ sử dụng, các nhóm đang ngày càng xây dựng các bộ chứng minh STARK cho các máy ảo tối thiểu được áp dụng rộng rãi như RISC-V. Bất kỳ chương trình nào cần được chứng minh việc thực thi đều có thể được biên dịch thành RISC-V và sau đó người chứng minh có thể chứng minh việc thực thi RISC-V của mã đó.



Sơ đồ từ tài liệu RiscZero

Điều này rất thuận tiện: nó có nghĩa là chúng ta chỉ cần viết logic chứng minh một lần , Từ đó trở đi, bất kỳ chương trình nào cần bằng chứng đều có thể được viết bằng bất kỳ ngôn ngữ lập trình "truyền thống" nào (ví dụ: RiskZero hỗ trợ Rust). Tuy nhiên, có một vấn đề: cách tiếp cận này phát sinh rất nhiều chi phí. Mã hóa có thể lập trình đã cực kỳ tốn kém; việc bổ sung thêm chi phí chạy mã trong trình thông dịch RISC-V là quá nhiều. Vì vậy, các nhà phát triển đã nghĩ ra một mẹo: xác định các hoạt động tốn kém cụ thể chiếm phần lớn tính toán (thường là hàm băm và chữ ký), sau đó tạo các mô-đun chuyên dụng để chứng minh các hoạt động đó rất hiệu quả. Sau đó, bạn chỉ cần kết hợp hệ thống chứng minh RISC-V kém hiệu quả nhưng chung chung với hệ thống chứng minh hiệu quả nhưng chuyên dụng và tận dụng tối đa cả hai thế giới.

Mã hóa có thể lập trình khác ngoài ZK-SNARK, chẳng hạn như tính toán nhiều bên (MPC) và mã hóa đồng hình hoàn toàn (FHE), có thể được tối ưu hóa bằng các phương pháp tương tự.

Nói chung là có hiện tượng gì?

Điện toán hiện đại ngày càng đi theo cái mà tôi gọi là kiến ​​trúc keo và bộ đồng xử lý: bạn có một số thành phần "keo" trung tâm, rất linh hoạt nhưng kém hiệu quả, chịu trách nhiệm truyền dữ liệu giữa nhiều thành phần bộ đồng xử lý có tính tổng quát thấp nhưng cao hiệu quả.



Đây là sự đơn giản hóa : Trong thực tế, đường cong đánh đổi giữa hiệu quả và tính linh hoạt hầu như luôn có nhiều hơn hai cấp độ. GPU và các chip khác, thường được gọi trong ngành là "bộ đồng xử lý", kém linh hoạt hơn CPU nhưng linh hoạt hơn ASIC. Sự đánh đổi chuyên môn hóa rất phức tạp và phụ thuộc vào dự đoán và trực giác về phần nào của thuật toán sẽ giữ nguyên sau 5 năm và phần nào sẽ thay đổi sau 6 tháng. Trong kiến ​​trúc chứng minh ZK, chúng ta thường thấy nhiều lớp chuyên môn hóa tương tự nhau. Nhưng đối với các mô hình tư duy rộng, chỉ cần xem xét hai cấp độ là đủ. Tình huống tương tự tồn tại trong nhiều lĩnh vực điện toán:

< / p>

Từ các ví dụ trên, có vẻ như đó là một quy luật tự nhiên khi các phép tính có thể được chia theo cách này. Trên thực tế, bạn có thể tìm thấy những ví dụ về chuyên môn hóa máy tính kéo dài hàng thập kỷ. Tuy nhiên, tôi nghĩ sự tách biệt này ngày càng gia tăng. Tôi nghĩ có lý do cho điều này:

Gần đây, chúng tôi mới đạt đến giới hạn cải thiện tốc độ xung nhịp CPU, vì vậy chỉ có thể đạt được nhiều lợi ích hơn nữa thông qua quá trình song song hóa. Tuy nhiên, rất khó để lý giải việc song song hóa, do đó, sẽ thực tế hơn nếu các nhà phát triển tiếp tục lý luận tuần tự và để việc song song hóa diễn ra ở phần phụ trợ, được bao bọc trong các mô-đun chuyên biệt được xây dựng cho các hoạt động cụ thể.

Việc tính toán gần đây chỉ trở nên nhanh đến mức chi phí tính toán của logic nghiệp vụ thực sự trở nên không đáng kể. Trong thế giới này, việc tối ưu hóa các máy ảo chạy logic nghiệp vụ để đạt được các mục tiêu khác ngoài hiệu quả tính toán cũng rất hợp lý: sự thân thiện với nhà phát triển, sự quen thuộc, bảo mật và các mục tiêu tương tự khác. Trong khi đó, các mô-đun "bộ đồng xử lý" chuyên dụng có thể tiếp tục được thiết kế để mang lại hiệu quả và đạt được tính bảo mật cũng như tính thân thiện với nhà phát triển từ "giao diện" tương đối đơn giản với chất kết dính.

Ngày càng rõ ràng những hoạt động tốn kém quan trọng nhất là gì. Điều này được thể hiện rõ nhất trong mật mã, trong đó các loại phép toán đắt tiền cụ thể có nhiều khả năng được sử dụng nhất: số học mô-đun, kết hợp tuyến tính của các đường cong elip (còn gọi là phép nhân đa vô hướng), phép biến đổi Fourier nhanh, v.v. Điều này cũng ngày càng trở nên rõ ràng trong trí tuệ nhân tạo, nơi trong hơn hai thập kỷ, hầu hết các phép tính đều là "nhân ma trận" (mặc dù có mức độ chính xác khác nhau). Xu hướng tương tự đang nổi lên ở các khu vực khác. Có ít ẩn số chưa biết hơn trong tính toán (chuyên sâu về tính toán) so với 20 năm trước.

Điều này có nghĩa là gì?

Điểm mấu chốt là bộ dán phải được tối ưu hóa để trở thành bộ đồng xử lý tốt và bộ đồng xử lý phải được tối ưu hóa để trở thành bộ đồng xử lý tốt. Chúng ta có thể khám phá những tác động của điều này trong một số lĩnh vực chính.

EVM

Một máy ảo blockchain (ví dụ EVM) không cần phải hiệu quả, chỉ cần quen thuộc. Chỉ bằng cách thêm bộ đồng xử lý phù hợp (còn gọi là "biên dịch trước"), các phép tính trong một máy ảo kém hiệu quả thực sự có thể hiệu quả như các phép tính trong một máy ảo hiệu quả nguyên bản. Ví dụ: chi phí mà các thanh ghi 256-bit của EVM phải chịu là tương đối nhỏ, trong khi lợi ích từ sự quen thuộc của EVM và hệ sinh thái nhà phát triển hiện tại là đáng kể và lâu dài. Các nhóm phát triển tối ưu hóa EVM thậm chí còn nhận thấy rằng việc thiếu tính song song thường không phải là rào cản lớn đối với khả năng mở rộng.

Cách tốt nhất để cải thiện EVM có thể chỉ là (i) thêm các mã opcode được biên dịch sẵn hoặc chuyên dụng tốt hơn, một số sự kết hợp giữa EVM-MAX và SIMD có thể hợp lý và (ii) cải thiện khả năng lưu trữ. Các thay đổi về bố cục, ví dụ: , Cây Verkle, như một tác dụng phụ, giúp giảm đáng kể chi phí truy cập vào các khe lưu trữ liền kề nhau.



Tối ưu hóa bộ nhớ trong đề xuất cây Ethereum Verkle, đặt các khóa lưu trữ liền kề với nhau và điều chỉnh chi phí gas để phản ánh điều này. Những tối ưu hóa như thế này, cùng với quá trình biên dịch trước tốt hơn, có thể quan trọng hơn việc điều chỉnh EVM.

Máy tính an toàn và phần cứng mở

Để cải thiện tính bảo mật của máy tính hiện đại ở phần cứng Thách thức cấp một là tính chất quá phức tạp và độc quyền của nó: các chip được thiết kế để hoạt động hiệu quả, đòi hỏi phải tối ưu hóa độc quyền. Các cửa hậu rất dễ ẩn giấu và các lỗ hổng kênh bên liên tục được phát hiện.

Những nỗ lực nhằm thúc đẩy các lựa chọn thay thế cởi mở và an toàn hơn vẫn tiếp tục từ nhiều góc độ. Một số hoạt động điện toán ngày càng được thực hiện trong môi trường thực thi đáng tin cậy, bao gồm cả trên điện thoại của người dùng, điều này đã cải thiện tính bảo mật của người dùng. Việc thúc đẩy nhiều phần cứng tiêu dùng nguồn mở hơn vẫn tiếp tục, với một số chiến thắng gần đây như máy tính xách tay RISC-V chạy Ubuntu.



Máy tính xách tay RISC-V chạy Debian

Tuy nhiên, hiệu quả vẫn là một vấn đề. Tác giả của bài báo được liên kết ở trên viết:

Các thiết kế chip nguồn mở mới hơn như RISC-V khó có thể cạnh tranh với công nghệ bộ xử lý đã tồn tại và đã được cải tiến qua nhiều thập kỷ. Sự tiến bộ luôn có điểm khởi đầu.

Những ý tưởng hoang tưởng hơn, chẳng hạn như thiết kế xây dựng máy tính RISC-V trên FPGA, phải đối mặt với chi phí lớn hơn. Nhưng điều gì sẽ xảy ra nếu kiến ​​trúc dán và bộ đồng xử lý có nghĩa là chi phí chung này không thực sự quan trọng? Nếu chúng tôi chấp nhận rằng các chip mở và bảo mật sẽ chậm hơn các chip độc quyền, thậm chí từ bỏ các tối ưu hóa phổ biến như thực thi suy đoán và dự đoán nhánh nếu cần, nhưng cố gắng bù đắp điều này bằng cách thêm các mô-đun ASIC (nếu cần, độc quyền) được sử dụng trong hầu hết các chương trình Chuyên sâu. các loại tính toán cụ thể, còn điều đó thì sao? Điện toán nhạy cảm có thể được thực hiện trong một "chip chủ" sẽ được tối ưu hóa về bảo mật, thiết kế nguồn mở và khả năng chống kênh bên. Các phép tính chuyên sâu hơn (ví dụ: bằng chứng ZK, AI) sẽ được thực hiện trong các mô-đun ASIC, mô-đun này sẽ biết ít thông tin hơn về các phép tính đang được thực hiện (có thể, thông qua việc làm mờ mật mã, thậm chí không có thông tin trong một số trường hợp).

Mật mã học

Một điểm quan trọng khác là tất cả đều rất lạc quan về việc mật mã học, đặc biệt là mật mã lập trình đang trở thành xu hướng chủ đạo. Chúng tôi đã thấy một số cách triển khai siêu tối ưu hóa một số phép tính có cấu trúc cao nhất định trong SNARK, MPC và các cài đặt khác: một số hàm băm chỉ đắt hơn vài trăm lần so với việc chạy tính toán trực tiếp và trí tuệ nhân tạo (chủ yếu là phép nhân ma trận) Chi phí chung cũng là rất thấp. Những cải tiến hơn nữa như GKR có thể làm giảm mức này hơn nữa. Việc thực thi VM hoàn toàn chung, đặc biệt là khi được thực thi trong trình thông dịch RISC-V, có thể sẽ tiếp tục phải chịu chi phí cao hơn khoảng mười nghìn lần, nhưng vì những lý do được mô tả trong bài viết này, điều này không thành vấn đề: miễn là có các kỹ thuật chuyên dụng hiệu quả. được sử dụng tương ứng Bằng cách xử lý các phần đòi hỏi nhiều tính toán nhất, chi phí tổng thể có thể được kiểm soát.



Sơ đồ đơn giản hóa của MPC dành riêng cho phép nhân ma trận, là thành phần lớn nhất trong suy luận mô hình AI. Xem bài viết này để biết thêm chi tiết, bao gồm cách giữ mô hình và thông tin đầu vào của bạn ở chế độ riêng tư.

Một ngoại lệ đối với quan điểm cho rằng "các lớp keo chỉ cần quen thuộc, không hiệu quả" là độ trễ và ở mức độ thấp hơn là băng thông dữ liệu. Nếu quá trình tính toán bao gồm các thao tác nặng trên cùng một dữ liệu hàng chục lần (như trong mật mã và trí tuệ nhân tạo), thì bất kỳ sự chậm trễ nào do các lớp keo không hiệu quả gây ra đều có thể trở thành nút thắt cổ chai lớn trong thời gian chạy. Vì vậy, dây chuyền dán keo cũng có những yêu cầu về hiệu quả, mặc dù những yêu cầu này cụ thể hơn.

Kết luận

Nhìn chung, tôi cho rằng những xu hướng trên là những bước phát triển rất tích cực xét từ nhiều góc độ. Đầu tiên, đây là cách hợp lý để tối đa hóa hiệu quả tính toán trong khi vẫn duy trì sự thân thiện với nhà phát triển, nhận được nhiều hơn cả hai vì lợi ích cá nhân. Đặc biệt, nó cải thiện khả năng của chúng tôi trong việc chạy các tính toán nhạy cảm và đòi hỏi hiệu năng (ví dụ: bằng chứng ZK, suy luận LLM) cục bộ trên phần cứng của người dùng bằng cách cho phép chuyên môn hóa ở phía máy khách để đạt hiệu quả cao hơn. Thứ hai, nó tạo ra cơ hội lớn để đảm bảo rằng việc theo đuổi hiệu quả không ảnh hưởng đến các giá trị khác, rõ ràng nhất là an toàn Bảo mật, cởi mở, và tính đơn giản: Tính mở và bảo mật kênh bên trong phần cứng máy tính, giảm độ phức tạp của mạch trong ZK-SNARK và giảm độ phức tạp trong máy ảo. Trong lịch sử, việc theo đuổi hiệu quả đã khiến những yếu tố khác này bị xếp sau. Với kiến ​​trúc keo và bộ đồng xử lý, nó không còn cần thiết nữa. Một phần của máy tối ưu hóa hiệu quả, phần khác tối ưu hóa tính linh hoạt và các giá trị khác, cả hai đều hoạt động cùng nhau.

Xu hướng này cũng rất tốt cho mật mã, bản thân nó là một ví dụ điển hình về "điện toán có cấu trúc đắt tiền" và xu hướng này đang đẩy nhanh xu hướng này. Điều này thêm một cơ hội khác để cải thiện an ninh. Tính bảo mật cũng được cải thiện trong thế giới blockchain: chúng ta có thể bớt lo lắng hơn về việc tối ưu hóa máy ảo và tập trung nhiều hơn vào việc tối ưu hóa quá trình biên dịch trước và các tính năng khác cùng tồn tại với máy ảo.

Thứ ba, xu hướng này mang đến cơ hội cho những người chơi nhỏ hơn, mới hơn tham gia. Nếu điện toán trở nên ít đơn lẻ hơn và mang tính mô-đun hơn, điều này sẽ làm giảm đáng kể rào cản gia nhập. Ngay cả việc sử dụng ASIC cho một loại máy tính cũng có thể tạo ra sự khác biệt. Điều này cũng đúng trong lĩnh vực chứng minh ZK và tối ưu hóa EVM. Viết mã với hiệu quả gần như tiên tiến trở nên dễ dàng và dễ tiếp cận hơn. Việc kiểm tra và xác minh chính thức mã đó trở nên dễ dàng và dễ tiếp cận hơn. Cuối cùng, vì các lĩnh vực điện toán rất khác nhau này đang hội tụ trên một số mô hình chung nên sẽ có nhiều không gian hơn cho sự cộng tác và học hỏi giữa chúng.