Tiêu đề gốc: Kiến trúc keo và bộ đồng xử lý
Tác giả gốc: Vitalik Buterin, người sáng lập Ethereum
Biên soạn gốc: Đặng Tông, 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 vì những phản hồi và nhận xét của họ.
Nếu bạn phân tích ở mức độ chi tiết 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 đi tìm lại một đặc điểm là phép tính có thể được chia thành hai phần:
· Một lượng tương đối nhỏ logic nghiệp vụ phức tạp nhưng đòi hỏi nhiều tính toán;
· Rất nhiều “công việc đắt tiền” chuyên sâu nhưng có cấu trúc cao.
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 trước có kiến trúc kém hiệu quả hơn nhưng cần phải rất chung chung; dạng sau có kiến trúc ít tổng quát hơn nhưng cần phải rất hiệu quả.
Một số ví dụ về cách tiếp cận khác nhau 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 này đã tiêu thụ tổng cộng 46924 gas và có thể được phân loại theo các cách sau:
· Giá cơ bản: 21.000
· Dữ liệu cuộc gọi: 1.556 EVM
· Thực hiện: 24, 368 SLOAD
· Mã hiệu: 6.400 SSTORE
· Mã lệnh: 10, 100 LOG
· Mã hiệu: 2, 149
· Khác: 6.719
Theo dõi EVM của các bản cập nhật băm ENS. Cột áp chót là lượng gas tiêu thụ.
Ý nghĩa của câu chuyện là: 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 bao gồm tính toán) tập trung vào một số lượng rất nhỏ các hoạt động đắt tiền có cấu trúc: lưu trữ đọc và ghi, 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 trong calldata để trích xuất ID của bản ghi mà tôi đang cố gắng thiết lập, 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 của một khối 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. Đồng thời, 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, một lần nữa 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: có nghĩa là chúng ta chỉ cần viết logic chứng minh một lần và từ đó trở đi, bất kỳ chương trình nào cần chứng minh đề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 đã rất 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ự.
Nhìn chung hiện tượng đó như thế nào?
Điện toán hiện đại ngày càng tuân theo những gì 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 chạy các tác vụ giữa một hoặc nhiều thành phần bộ đồng xử lý này có tính tổng quát thấp nhưng hiệu quả truyền tải cao. dữ liệu giữa chúng.
Đâ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 những 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:
Từ các ví dụ trên, chắc chắn có vẻ như một quy luật tự nhiên là 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 việc 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ể.
Tố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 VM mà logic nghiệp vụ chạy trên đó để đạ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 thể hiện rõ nhất trong mật mã, trong đó một số loại phép toán đắt tiền thường được sử dụng nhất: phép toán mô đun, 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 chủ yếu là phép 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 điện toán (chuyên sâu về tính toán) so với 20 năm trước.
điều đó có nghĩa là gì?
Điểm mấu chốt là keo phải được tối ưu hóa để trở thành keo 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áy ảo blockchain (ví dụ EVM) không cần hiệu quả, chỉ cần quen thuộc. Chỉ cần 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 opcode được biên dịch trước hoặc chuyên dụng tốt hơn, ví dụ như một số kết hợp giữa EVM-MAX và SIMD có thể hợp lý và (ii) cải thiện bố cục bộ nhớ, chẳng hạn như của 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 lưu trữ 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.
Điện toán an toàn và phần cứng mở
Một trong những thách thức trong việc cải thiện tính bảo mật trong điện toán hiện đại ở cấp độ phần cứng là tính chất quá phức tạp và độc quyền của nó: 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 tiếp tục thúc đẩy các giải pháp thay thế mở và an toàn hơn 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 viết đượ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, như thiết kế xây dựng máy tính RISC-V trên FPGA này, 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? Các phép tính nhạy cảm có thể được thực hiện trong chip chính, chip này 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 phụ. 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ã
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ã, đặc biệt là mật mã có thể 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ố tính toán 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ể 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 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 tính toán nhiều 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, 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.
Tóm lại
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, đó là một cách hợp lý để tối đa hóa hiệu quả tính toán trong khi vẫn thân thiện với nhà phát triển và việc có thể khai thác được nhiều hơn cả hai tính năng này là điều tốt cho tất cả mọi người. Đặ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 suất (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 một 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, đáng chú ý nhất là tính bảo mật, tính mở và tính đơn giản: tính mở và tính 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 tạo 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 nguyên khối 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 một loại ASIC tính toán 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.
