Lộ trình hiệu suất của Starknet

Resident

02/12/2022 18:37

2422

TL;DR

Bản tổng hợp hợp lệ không bị giới hạn về thông lượng giống như L1. Điều này dẫn đến TPS có khả năng cao hơn nhiều khi tổng hợp hiệu lực L2.
Lộ trình hiệu suất của Starknet giải quyết một yếu tố quan trọng trong hệ thống: trình sắp xếp thứ tự.
Ở đây chúng tôi trình bày lộ trình cải thiện hiệu suất:
— Song song hóa trình tự
— Một triển khai rỉ sét mới cho máy ảo Cairo
— Triển khai lại trình tuần tự trong rỉ sét\
Những người chuyên nghiệp, đã được thử nghiệm trong trận chiến, không phải là nút thắt cổ chai và có thể xử lý nhiều hơn những gì họ làm hiện tại!

Giới thiệu

Starknet ra mắt trên Mainnet gần một năm trước. Chúng tôi bắt đầu xây dựng Starknet bằng cách tập trung vào chức năng. Giờ đây, chúng tôi chuyển trọng tâm sang cải thiện hiệu suất bằng một loạt bước sẽ giúp nâng cao trải nghiệm Starknet.

Trong bài đăng này, chúng tôi giải thích lý do tại sao có nhiều biện pháp tối ưu hóa chỉ áp dụng được trong các bản tổng hợp hợp lệ và chúng tôi sẽ chia sẻ kế hoạch triển khai các bước này trên Starknet. Một số bước này đã được triển khai trong Starknet Alpha 0.10.2, được phát hành trên Testnet vào ngày 16 tháng 11 và Hôm qua trên Mainnet. Nhưng trước khi thảo luận về các giải pháp, chúng ta hãy xem xét những hạn chế và nguyên nhân của chúng.

Giới hạn khối: tổng hợp hiệu lực so với L1

Một cách tiếp cận tiềm năng hướng tới việc tăng khả năng mở rộng blockchain và tăng TPS sẽ là dỡ bỏ các giới hạn khối (về gas/kích thước) trong khi vẫn giữ thời gian khối không đổi. Điều này sẽ đòi hỏi nhiều nỗ lực hơn từ các nhà sản xuất khối (trình xác nhận trên L1, trình xác thực trên L2) và do đó đòi hỏi việc triển khai các thành phần đó hiệu quả hơn. Vì mục đích này, giờ đây chúng tôi chuyển trọng tâm sang tối ưu hóa trình sắp xếp chuỗi Starknet mà chúng tôi sẽ mô tả chi tiết hơn trong các phần sau.

Một câu hỏi tự nhiên được đặt ra ở đây. Tại sao việc tối ưu hóa trình sắp xếp chuỗi bị giới hạn ở các lần tổng hợp tính hợp lệ, nghĩa là tại sao chúng tôi không thể triển khai các cải tiến tương tự trên L1 và tránh hoàn toàn sự phức tạp của việc tổng hợp tính hợp lệ? Trong phần tiếp theo, chúng tôi khẳng định rằng có sự khác biệt cơ bản giữa hai điều này, cho phép thực hiện nhiều tối ưu hóa trên L2 mà không thể áp dụng cho L1.

Tại sao thông lượng L1 bị hạn chế?

Thật không may, việc dỡ bỏ các giới hạn khối trên L1 gặp phải một cạm bẫy lớn. Bằng cách tăng tốc độ tăng trưởng của chuỗi, chúng tôi cũng tăng nhu cầu từ các nút đầy đủ, những người đang cố gắng theo kịp trạng thái gần đây nhất. Vì các nút đầy đủ L1 phải thực hiện lại tất cả lịch sử, nên việc kích thước khối tăng cao (về mặt gas) sẽ gây áp lực đáng kể cho chúng, một lần nữa dẫn đến việc các máy yếu hơn sẽ rời khỏi hệ thống và khiến khả năng chạy các nút đầy đủ bị mất chỉ cho các thực thể đủ lớn. Do đó, người dùng sẽ không thể tự xác minh trạng thái và tham gia vào mạng một cách đáng tin cậy.

Điều này khiến chúng tôi hiểu rằng thông lượng L1 nên được giới hạn để duy trì một hệ thống thực sự phi tập trung và an toàn.

Tại sao các rào cản tương tự không ảnh hưởng đến tổng hợp hiệu lực?

Chỉ khi xem xét phối cảnh nút đầy đủ, chúng ta mới thấy sức mạnh thực sự được cung cấp bởi các bản tổng hợp hợp lệ. Nút đầy đủ L1 cần thực hiện lại toàn bộ lịch sử để đảm bảo tính chính xác của trạng thái hiện tại. Các nút Starknet chỉ cần xác minh bằng chứng STARK và việc xác minh này tiêu tốn lượng tài nguyên tính toán thấp hơn theo cấp số nhân. Đặc biệt, việc đồng bộ hóa từ đầu không nhất thiết phải thực thi; một nút có thể nhận được kết xuất trạng thái hiện tại từ các nút ngang hàng của nó và chỉ xác minh thông qua bằng chứng STARK rằng trạng thái này là hợp lệ. Điều này cho phép chúng tôi tăng thông lượng của mạng mà không làm tăng yêu cầu đối với nút đầy đủ.

Do đó, chúng tôi kết luận rằng trình sắp xếp chuỗi L2 phải tuân theo toàn bộ phổ tối ưu hóa mà L1 không thể thực hiện được.

Lộ trình hiệu suất phía trước

Trong các phần tiếp theo, chúng ta sẽ thảo luận về những phần nào hiện đang được lên kế hoạch cho trình sắp xếp chuỗi Starknet.

Song song hóa trình tự

Bước đầu tiên trong lộ trình của chúng tôi là triển khai tính năng song song hóa trong quá trình thực hiện giao dịch. Điều này đã được giới thiệu trong Starknet alpha 0.10.2, được phát hành hôm qua trên Mainnet. Bây giờ chúng ta đi sâu vào xem song song hóa là gì (đây là phần bán kỹ thuật, để tiếp tục lộ trình, hãy chuyển sang phần tiếp theo).

Vậy “song song hóa giao dịch” nghĩa là gì? Một cách ngây thơ, việc thực hiện song song một khối giao dịch là không thể vì các giao dịch khác nhau có thể phụ thuộc vào nhau. Điều này được minh họa trong ví dụ sau đây. Hãy xem xét một khối có ba giao dịch từ cùng một người dùng:

Giao dịch A: hoán đổi USDC lấy ETH
Giao dịch B: thanh toán ETH cho NFT
Giao dịch C: hoán đổi USDT lấy BTC

Rõ ràng, Tx A phải xảy ra trước Tx B, nhưng Tx C hoàn toàn độc lập với cả hai và có thể được thực thi song song. Nếu mỗi giao dịch cần 1 giây để thực hiện thì thời gian sản xuất khối có thể giảm từ 3 giây xuống còn 2 giây bằng cách triển khai song song.

Mấu chốt của vấn đề là chúng ta không biết trước sự phụ thuộc của giao dịch. Trong thực tế, chỉ khi thực hiện giao dịch B từ ví dụ của mình, chúng ta mới thấy rằng nó dựa vào những thay đổi do giao dịch A thực hiện. Chính thức hơn, sự phụ thuộc xuất phát từ thực tế là giao dịch B đọc từ các ô lưu trữ mà giao dịch A đã ghi vào. Chúng ta có thể coi các giao dịch như hình thành một biểu đồ phụ thuộc, trong đó có một cạnh từ giao dịch A đến giao dịch B nếu A ghi vào một ô lưu trữ được B đọc và do đó phải được thực thi trước B. Hình dưới đây cho thấy một ví dụ về biểu đồ phụ thuộc như vậy:

Trong ví dụ trên, mỗi cột có thể được thực hiện song song và đây là cách sắp xếp tối ưu (nghe một cách ngây thơ thì chúng ta sẽ thực hiện các giao dịch từ 1 đến 9 theo tuần tự).

Để khắc phục thực tế là biểu đồ phụ thuộc không được biết trước, chúng tôi giới thiệu tính năng song song lạc quan, theo tinh thần BLOCK-STM do Aptos Labs phát triển, cho trình sắp xếp chuỗi Starknet. Theo mô hình này, chúng tôi cố gắng chạy các giao dịch song song một cách lạc quan và thực hiện lại khi phát hiện xung đột. Ví dụ: chúng ta có thể thực hiện song song các giao dịch 1–4 từ hình 1, chỉ để sau đó phát hiện ra rằng Tx4 phụ thuộc vào Tx1. Do đó, việc thực thi nó là vô ích (chúng tôi đã chạy nó tương đối với cùng trạng thái mà chúng tôi đã chạy Tx1, trong khi lẽ ra chúng tôi nên chạy nó theo trạng thái do áp dụng Tx1). Trong trường hợp đó, chúng tôi sẽ thực hiện lại Tx4.

Lưu ý rằng chúng ta có thể thêm nhiều tối ưu hóa bên cạnh khả năng song song hóa tối ưu. Ví dụ: thay vì ngây thơ chờ đợi mỗi lần thực thi kết thúc, chúng ta có thể hủy bỏ một lần thực thi ngay khi chúng ta tìm thấy một phần phụ thuộc làm mất hiệu lực của nó.

Một ví dụ khác là tối ưu hóa việc lựa chọn thực hiện lại giao dịch nào. Giả sử rằng một khối bao gồm tất cả các giao dịch từ hình 1 được đưa vào bộ tuần tự có năm lõi CPU. Đầu tiên, chúng tôi cố gắng thực hiện song song các giao dịch 1–5. Nếu thứ tự hoàn thành là Tx2, Tx3, Tx4, Tx1 và cuối cùng là Tx5 thì chúng ta sẽ tìm thấy sự phụ thuộc Tx1→Tx4 chỉ sau khi Tx4 đã được thực thi – cho biết rằng nó cần được thực thi lại. Ngây thơ, chúng tôi cũng có thể muốn thực thi lại Tx5 vì nó có thể hoạt động khác đi khi thực hiện Tx4 mới. Tuy nhiên, thay vì chỉ thực hiện lại tất cả các giao dịch sau Tx4 hiện không còn hiệu lực, chúng ta có thể duyệt qua biểu đồ phụ thuộc được xây dựng từ các giao dịch mà việc thực thi đã chấm dứt và chỉ thực hiện lại các giao dịch phụ thuộc vào Tx4.

Triển khai Rust mới cho Cairo-VM

Hợp đồng thông minh trong Starknet được viết bằng Cairo và được thực thi bên trong Cairo-VM, thông số kỹ thuật này xuất hiện trên tờ báo Cairo . Hiện tại, trình sắp xếp chuỗi đang sử dụng triển khai python của Cairo-VM. Để tối ưu hóa hiệu suất triển khai VM, chúng tôi đã nỗ lực viết lại VM trong tình trạng rỉ sét. Nhờ vào công việc tuyệt vời của Lambdaclass , những người hiện là một nhóm vô giá trong hệ sinh thái Starknet, nỗ lực này sẽ sớm thành hiện thực.

Quá trình triển khai rỉ sét của VM, cairo-rs , hiện có thể thực thi mã Cairo gốc. Bước tiếp theo là xử lý việc thực thi và tích hợp hợp đồng thông minh với trình sắp xếp Pythonic. Sau khi được tích hợp với cairo-rs, hiệu suất của trình sắp xếp chuỗi dự kiến sẽ được cải thiện đáng kể.

Triển khai lại trình tự sắp xếp trong Rust

Việc chúng tôi chuyển từ trăn sang rỉ sét để cải thiện hiệu suất không chỉ giới hạn ở Cairo VM. Bên cạnh những cải tiến được đề cập ở trên, chúng tôi dự định viết lại trình sắp xếp thứ tự từ đầu trong tình trạng rỉ sét. Ngoài những lợi thế bên trong của Rust, điều này còn mang đến cơ hội tối ưu hóa khác cho trình sắp xếp chuỗi. Liệt kê một số cặp, chúng ta có thể tận hưởng những lợi ích của cairo-rs mà không cần tốn chi phí liên lạc với python-rust và chúng ta hoàn toàn có thể thiết kế lại cách trạng thái được lưu trữ và truy cập (ngày nay dựa trên cấu trúc Patricia-Trie ) .

Còn người chứng minh thì sao?

Trong suốt bài đăng này, chúng tôi đã không đề cập đến yếu tố có lẽ nổi tiếng nhất của việc tổng hợp tính hợp lệ – người chứng minh. Người ta có thể tưởng tượng rằng được cho là thành phần phức tạp nhất của kiến trúc, nó phải là nút cổ chai và do đó, là trọng tâm của việc tối ưu hóa. Điều thú vị là các thành phần “tiêu chuẩn” hơn hiện đang là điểm nghẽn của Starknet. Ngày nay, đặc biệt là với các bằng chứng đệ quy , chúng tôi có thể đưa nhiều giao dịch hơn lưu lượng truy cập hiện tại trên Testnet/Mainnet vào một bằng chứng. Trên thực tế, ngày nay, các khối Starknet đã được chứng minh cùng với các giao dịch của StarkEx, trong đó các giao dịch sau đôi khi có thể phát sinh hàng trăm nghìn NFT.