Tốc độ kỹ thuật: Bên trong đội ngũ hiệu năng của Anza cùng Alessandro Decina

Giới thiệu

Không còn nghi ngờ gì nữa, tinh thần lạc quan về công nghệ là đặc trưng văn hóa của Solana. Niềm tin tuyệt đối vào tốc độ, tiến bộ và đổi mới không giới hạn là nền tảng của mọi pull request được đưa lên mainnet. Khẩu hiệu là IBRL: Tăng băng thông, giảm độ trễ. Nó vừa là mệnh lệnh kỹ thuật, vừa là dấu hiệu nhận diện văn hóa, vừa là lời cầu nguyện thế tục. Nếu Bitcoin là thánh đường của sự trường tồn và Ethereum là quảng trường của tính trung lập, thì Solana là một trường đua: nơi tốc độ cơ học có thể đo lường được.

Thế nhưng tốc độ này không bao giờ từ trên trời rơi xuống dưới dạng một diff được chú thích gọn gàng. Nó được khai phá, mài giũa và tạo nên bởi những người dám nhìn chằm chằm vào code cả ngày. Hiếm ai làm điều đó quyết liệt hơn Alessandro Decina, vốn là một bậc thầy GStreamer xem hiện tượng giật hình trong bộ đệm video như một sự xúc phạm cá nhân. Hiện nay, anh dẫn dắt đội ngũ hiệu năng bốn người của Anza, nơi khái niệm “tự chăm sóc bản thân” là xóa các thanh màu vàng khỏi trace của validator lúc 3 giờ sáng. Công việc hằng ngày của họ gồm nhìn vào flame graph, loại bỏ toàn bộ quy trình và viết lại code production đã được thử thách thực tế, bởi bất cứ thứ gì có thể tối ưu thì cuối cùng cũng sẽ được tối ưu.

Tôi muốn hiểu sống ở tốc độ này có ý nghĩa gì. Vì vậy, tôi đã ngồi lại với chính Alessandro Decina để tìm hiểu cách anh tiếp tục khiến blockchain nhanh nhất hiện nay còn nhanh hơn nữa. Cuộc phỏng vấn sau đây là một cuộc khám nghiệm tốc độ. Chúng tôi thảo luận từ những ngày anh làm việc với pipeline đa phương tiện cho đến các rào chắn văn hóa giúp bốn kỹ sư có thể triển khai nhiều hơn cả những tổ chức lớn.

Cuộc trò chuyện đã được biên tập và rút gọn để rõ ràng, súc tích hơn.

Phỏng vấn

Khởi nguồn và thế giới quan

Ichigo: Nhìn lại quá khứ, tình yêu đầu tiên của anh là GStreamer và các pipeline đa phương tiện. Những bài học lớn nhất về độ trễ từ thời kỳ đó là gì? Việc theo đuổi âm thanh và video thời gian thực đã dạy anh điều gì về cách cắt giảm từng mili giây cho Agave?

Decina: Trước hết, làm tốt lắm khi đã điều tra tôi, haha. Tôi đã làm việc với GStreamer khoảng 15 năm, có thể lâu hơn một chút. Đó thực sự là nơi tôi học được mọi thứ mình biết. Tôi bắt đầu đóng góp cho dự án khi nó còn là mã nguồn mở và mới khởi đầu. Tôi rất may mắn khi có cơ hội gần gũi với nhà sáng lập lúc đó. Anh ấy hơn tôi khoảng 15 tuổi và cực kỳ giỏi. Kiểu như, người này có trang Wikipedia, hẳn là thông minh lắm. Không giống tôi—tôi chỉ giả vờ thông minh thôi. Anh ấy đơn giản quyết định rằng, ừ, sao cũng được, tôi sẽ dạy miễn phí cho cậu mọi thứ tôi biết. Và thế là tôi bắt đầu làm việc với nó.

Thật buồn cười khi giờ đây chúng ta nói về độ trễ thấp trong lúc làm việc với Solana, bởi vì đây hoàn toàn không phải độ trễ thấp. Khi nói về xử lý âm thanh, DPS và phần cứng đa phương tiện, những gì chúng ta làm trên Solana có độ trễ cực cao. Nếu bất kỳ hệ thống âm thanh hoặc video nào có thời gian phản hồi 400 mili giây, về cơ bản nó đã hỏng. Như vậy là không thể hoạt động.

Đến một thời điểm, tôi bắt đầu làm việc với driver Linux cùng phần cứng mã hóa và giải mã video, âm thanh. Nhiều việc tôi làm ngày nay về cơ bản giống hệt những gì tôi làm khi đó. Khi làm việc với phần cứng, độ trễ đồng nghĩa với việc có một hàng đợi ở đâu đó. Bạn tìm hàng đợi đó, cố gắng thu nhỏ nó hết mức có thể và đảm bảo nó không bao giờ bị thiếu dữ liệu.

Ví dụ, công việc XDP tôi đang làm hiện nay rất giống cách hoạt động của ring buffer âm thanh. Ngay cả cuộc gọi hiện tại của chúng ta cũng có hàng loạt packet đến không đúng thứ tự. Có một ring buffer ở đâu đó sắp xếp lại toàn bộ packet và chắc chắn bạn muốn bảo đảm nó không bị thiếu dữ liệu.

Tôi có cảm giác mình đã làm cùng một công việc suốt 20 năm qua.

Có thể nói là vẫn chuyện đó, chỉ khác ngày. Vì tôi cũng nhận thấy anh từng làm việc tại Spotify và có liên quan đôi chút đến Firefox—

À, không, phần Firefox chỉ là công việc tích hợp cho một hackathon. Haha, tôi già đến mức đã viết video tag nguyên bản cho Firefox sử dụng GStreamer.

Ghê thật, haha. Vậy mọi con đường đều dẫn về GStreamer à?

GStreamer thực sự đã dạy tôi lập trình đa luồng. Đó là lý do tôi có mặt trong hệ sinh thái này. Có những người viết Assembly và thực hiện đủ loại thủ thuật cấp thấp. Tôi thì nghĩ, ừ, mình đã làm việc đó từ lâu rồi. Và tôi đã học được rằng nếu không có một ngôn ngữ với hệ thống kiểu mạnh và compiler tốt, cuối cùng bạn sẽ tự gây họa cho mình. Tôi chắc chắn bạn có thể khiến thứ gì đó nhanh hơn đôi chút bằng Assembly, nhưng tôi thực sự muốn Rust.

Tôi muốn compiler Rust nói với mình: đồ ngốc—cái này sẽ không chạy vì ở đây có bug. Trước Rust, tôi cảm thấy mình chỉ có 10% là kỹ sư phần mềm và 90% là một trình gỡ lỗi bằng xương bằng thịt. Tôi chỉ toàn gỡ lỗi. Vì vậy, tôi nghĩ GStreamer và tình yêu dành cho Rust là lý do tôi bắt đầu làm việc với Solana. Rust đang trở nên phổ biến, không có nhiều công việc cho phép bạn làm toàn thời gian với nó, còn tôi đã quyết định mình sẽ chỉ làm việc với Rust.

Tôi quá già để còn viết C. Tôi không muốn dùng một ngôn ngữ không an toàn về bộ nhớ. Tôi không muốn lãng phí thời gian. Vậy nên, ừ, tôi ở đây.

Rất hay. Vậy khi chuyển hướng, trước lúc làm việc với code validator, anh có hiểu lầm nào về các hệ thống phi tập trung không? Điều gì thuyết phục anh rằng kiến trúc của Solana thực sự có thể mở rộng?

Thực ra cuối cùng tôi đã gia nhập Solana muộn gần hai năm vì bận làm việc với compiler Rust. Một người ở Solana vừa bắt đầu làm việc trên máy ảo đã gửi email nói: “Ồ, tôi đang làm cùng một thứ, có vẻ anh đã tiến xa hơn một chút, hãy đến làm việc với chúng tôi.” Tôi không trả lời email đó vì đã tìm hiểu Bitcoin rồi Ethereum và nhận ra rằng đúng là có thể thực thi mọi thứ, nhưng chỉ có 10 TPS. Nó đâu giống một dự án nghiêm túc, đúng không? Bạn không thể làm bất cứ điều gì trong thế giới thực với 10 TPS.

Vì vậy, khi nhận được email đó, tôi đã không trả lời. Tôi chỉ nghĩ, được rồi, những người làm crypto này vẫn chưa nghiêm túc.

Hai năm sau, Toly liên hệ và tôi kiểm tra giá SOL. Tôi nghĩ, được rồi, lẽ ra mình nên mở email đó, haha. Lần này tôi đã trò chuyện với anh ấy. Trước cuộc trò chuyện, anh ấy gửi cho tôi một số code. Tôi xem qua và thành thật mà nói, code rất tệ. Đây thực sự là code Rust rất tệ.

Nhưng sau đó tôi nói chuyện với Toly mà không tìm anh ấy trên Google, nên hoàn toàn không biết anh ấy là ai. Anh ấy thông minh và nói mọi điều đúng đắn. Anh ấy nói chúng tôi đang xây dựng thứ này. Hiện tại, chúng tôi làm theo cách này. Rõ ràng nó chưa phải công nghệ tiên tiến nhất, nhưng tham vọng là mở rộng theo phần cứng. Chúng tôi xây dựng blockchain có hiệu năng cao nhất, rồi phần cứng sẽ trở thành nút thắt cổ chai. Ý tưởng là càng bổ sung nhiều phần cứng, hệ thống càng mở rộng.

Điều đó đã thuyết phục tôi. Tôi cảm thấy đây không chỉ là một đám cuồng blockchain tự sướng với Thế chiến III… Tôi quan tâm đến công nghệ. Tôi là một trong số ít người làm crypto thực sự tham gia vì công nghệ.

Solana có một văn hóa kỹ thuật chịu ảnh hưởng mạnh từ tinh thần lạc quan về công nghệ—toàn bộ văn hóa Tăng băng thông, giảm độ trễ đó. Cá nhân anh nhìn nhận điều này thế nào? Nó ảnh hưởng ra sao đến công việc hằng ngày tại Anza?

Theo tôi, Ethereum về cơ bản mang tư duy khan hiếm. Họ nghĩ, được rồi, chúng ta đã đụng phải một số bức tường và sẽ tìm cách đi vòng qua chúng. Chúng ta sẽ phát minh ra toàn bộ cơ sở hạ tầng này để giải quyết những khoảng trống kiến thức mà mình có và cảm thấy không thể nào khắc phục được, đúng không?

Còn tôi cảm thấy chúng tôi hoàn toàn ngược lại. Kiểu như, được rồi, có một vấn đề. Không có vấn đề nào không thể giải quyết, ngoại trừ những thứ vi phạm định luật vật lý. Đây đơn giản là một khác biệt văn hóa rất lớn.

Nếu có thứ gì đó bị hỏng, chúng tôi chỉ nói, được rồi, hãy ngồi xuống. Hãy profile một chút để xem vấn đề nằm ở đâu. Hãy nói chuyện với trader và market maker. Hãy xem vấn đề của họ là gì. Gần đây, chúng tôi đã tìm thấy một số vấn đề rất cụ thể và khắc phục được phần lớn. Thực sự thì trong hai đến ba tháng, chúng tôi có thể xử lý tất cả.

Hiện nay có nhiều thứ trên Solana không hoạt động tốt. Chúng tôi biết về chúng và chưa bao giờ ngồi xuống rồi nói: “Chúng ta có giải pháp hoàn hảo! Và giờ để tiến xa hơn, chúng ta cần phát minh thứ gì đó mới hoặc phải nghiên cứu và làm điều khác.” Không—đây là những vấn đề cụ thể. Phần lớn thực sự là những vấn đề ngớ ngẩn.

Và gần đây chúng tôi không gặp sự cố ngừng hoạt động nào. Cá nhân tôi nghĩ đó là tín hiệu tiêu cực, đúng không? Vì tôi cho rằng một số người đã bắt đầu hơi bảo thủ. Chúng tôi biết mình có thể chạy nhanh hơn rất nhiều. Chúng tôi biết ngày mai mình có thể đạt block 100 triệu CU, đúng không? Chỉ cần cấp tốc xử lý một số thứ. Và tôi ủng hộ việc cấp tốc xử lý mọi thứ.

Về cơ bản, chúng tôi biết mình không cần roadmap để hiểu rằng hiệu năng hiện tại có thể tăng gấp 10 lần. Chúng tôi thấy được cách thực hiện. Chúng tôi biết cách thực hiện. Hoặc chúng tôi đã viết code nhưng chưa hoàn thiện hoàn toàn, hoặc đã viết xong code nhưng chưa thể triển khai vì vẫn còn một số trường hợp biên cần khắc phục. Nhưng chúng tôi biết chính xác phải làm gì.

Chúng tôi biết cách mở rộng hệ thống này.

Kỹ thuật hiệu năng

Nói về công việc hiệu năng, tôi nghĩ không nhiều người thực sự biết Anza có một đội ngũ chuyên trách về hiệu năng. Đội ngũ này khá ít được chú ý. Hãy chia sẻ một chút về cơ cấu của đội. Đội khác với các nhóm kỹ thuật khác tại Anza như thế nào?

Đúng vậy, chúng tôi có nhiều đội khác nhau tại Anza. Hiện tại có đội đồng thuận đang tập trung vào Alpenglow. Đội mạng chủ yếu tập trung vào Gossip. Đội AccountsDB về cơ bản chỉ làm việc với cơ sở dữ liệu account. Có đội sản xuất block làm việc trên scheduler. Và tất nhiên còn tất cả những đội khác mà tôi đang quên mất.

Điểm khác biệt của đội hiệu năng là chúng tôi làm việc trên mọi thứ. Chúng tôi profile, tìm nút thắt cổ chai rồi hỏi các đội liên quan xem họ có thời gian và chuyên môn hay không, bởi đôi khi chúng tôi tìm thấy những vấn đề mà không phải ai cũng có thể khắc phục. Ví dụ, nếu làm về đồng thuận, bạn không nhất thiết là người giỏi nhất về lập trình cấp thấp vì chuyên môn của bạn nằm ở nơi khác. Vì vậy, trong những trường hợp đó, chúng tôi thường trực tiếp vào sửa code cho họ.

Vì vậy, chúng tôi không chỉ làm một việc. Chúng tôi tìm nút thắt cổ chai tiếp theo. Khoảng hai tuần một lần, chúng tôi đồng bộ để xác định mình đang ở đâu, cần làm gì tiếp theo và làm cách nào để phiên bản tiếp theo nhanh hơn.

Một khác biệt lớn khác là Anza có xu hướng tuyển người thông minh. Chẳng hạn, nếu bạn không biết Rust thì cũng không sao. Nếu không biết lập trình cấp thấp thì cũng không sao. Chúng tôi cho rằng nếu bạn thông minh, phần lớn kỹ năng này có thể được đào tạo trong quá trình làm việc. Với đội hiệu năng, tôi thường tuyển những người thực sự có kinh nghiệm với kernel hoặc các lĩnh vực cấp thấp khác vì tính chất của những nút thắt cổ chai mà chúng tôi đang gặp.

Ví dụ, với cơ sở dữ liệu account, chúng tôi có một số vấn đề về thuật toán cần khắc phục. Nhưng*,* lý do cơ sở dữ liệu account trong bản phát hành 2.3 nhanh hơn khoảng mười lần so với hai tháng trước là vì chúng tôi đã sửa cách nó thực hiện I/O. Muốn làm nó nhanh hơn, bạn cần biết cơ chế đó hoạt động thế nào. Nếu chỉ hiểu cơ sở dữ liệu ở cấp độ cao, bạn không thực sự biết ổ đĩa hoạt động ra sao và cũng không cần biết kernel lên lịch các yêu cầu I/O như thế nào.

Vì vậy, riêng với đội hiệu năng, tôi có xu hướng tuyển nhiều người làm việc ở cấp thấp hơn. Một lần nữa, tôi thậm chí không quan tâm họ có biết Rust hay không, nhưng tôi muốn họ từng làm việc với C hoặc C++ trong các lĩnh vực cấp thấp khác.

Lý do ít người biết có một đội hiệu năng là vì về cơ bản chúng tôi mới bắt đầu vào tháng 12. Ban đầu tôi được tuyển để làm việc với compiler, nhưng đã chuyển sang hiệu năng vào khoảng thời gian xảy ra sự cố tháng 3 năm 2024 và bắt đầu tối ưu mọi thứ. Mọi người không vui lắm vì một ngày nọ tôi vừa nói với họ rằng mình sẽ làm bất cứ thứ gì mình muốn. Vậy nên, đúng vậy, haha, họ không vui, nhưng sau đó chúng tôi đạt được kết quả rất tốt. Thế là mọi người đến gặp tôi và nói: “Được rồi, thực ra anh có muốn tuyển thêm người để làm việc này không?” Sau đó, vào tháng 12, chúng tôi chính thức hóa nỗ lực cải thiện hiệu năng và thành lập đội.

Thành thật mà nói, tôi thiên vị, nhưng đội hiệu năng chắc chắn là đội giỏi nhất tại Anza, không phải bàn cãi.

Tôi không nghi ngờ điều đó, haha. Đội có bao nhiêu người?

Có bốn người làm toàn thời gian, nhưng tôi vẫn đùa trên Twitter về việc Brooks và một số người khác gia nhập vì tôi đã bắt đầu chia sẻ profiler của mình rộng rãi hơn. Cho đến khoảng hai tháng trước, chỉ người trong đội hiệu năng mới có quyền truy cập profiler. Giờ mọi người đều có profiler. Ví dụ, từ khi tôi đưa profiler cho Brooks, Brooks làm công việc hiệu năng còn nhiều hơn tôi, haha. Anh ấy hoàn toàn bị cuốn vào. Giờ anh ấy cứ làm mọi thứ nhanh hơn.

Vì vậy, hiện tại không chính thức còn có Brooks và vài người khác cũng làm rất nhiều việc về hiệu năng. Nhưng có bốn người chúng tôi làm toàn thời gian về hiệu năng.

Vậy khi làm việc về hiệu năng, đâu là một “dấu hiệu bất thường” mà anh tìm kiếm khi profile nhưng hầu hết kỹ sư sẽ bỏ sót? Anh quyết định cần tối ưu những gì bằng cách nào?

Có một số thứ cực kỳ rõ ràng. Chẳng hạn, khi mới bắt đầu profile Agave, chúng tôi dành nhiều thời gian bên trong kernel hơn hẳn so với việc thực thi code ở user space, điều này thật vô lý. Chúng tôi không phải một ứng dụng cấp thấp. Nếu là một framework đa phương tiện, việc thực hiện phần lớn công việc trong kernel sẽ hợp lý vì cuối cùng bạn cần gửi các sample đến phần cứng. Nhưng công việc thực sự mang tính cấp thấp duy nhất mà chúng tôi làm là Turbine.

Vì vậy, dấu hiệu bất thường lớn nhất khi tôi bắt đầu profile thường là thấy nhiều màu vàng trong flame graph, bởi điều đó có nghĩa chúng tôi dành quá nhiều thời gian trong kernel. Có thể ai đó đang sử dụng một API cấp cao trông vô hại, nhưng bên dưới lại có hiệu năng tệ khủng khiếp.

Trong năm qua, chúng tôi đã giảm lượng bộ nhớ Agave sử dụng khoảng 10 lần vì nhìn chung chúng tôi liên tục gặp cùng một vấn đề. Khi thực hiện quá nhiều lần cấp phát bộ nhớ, đến một lúc nào đó bạn phải bắt đầu tương tác với kernel. Bạn có thể thấy tương tác với kernel trong profiler. Bạn nhìn xem, được rồi, cái này đến từ đâu? Bạn thấy chuỗi này liên tục khuấy tung bộ nhớ. Bạn lần ngược nó về tận nơi đang liên tục thay đổi và cấp phát quá nhiều bộ nhớ rồi sửa lại.

Có một số vấn đề khó hơn. Ví dụ, chúng tôi đã phát hiện một vấn đề thiết kế nền tảng và tôi đang khắc phục nó. Ai cũng biết Solana sử dụng pipeline với nhiều giai đoạn khác nhau và lẽ ra mọi thứ phải được song song hóa để chạy đồng thời.

Trên thực tế, do cách kiến trúc hệ thống được xây dựng, chúng tôi có thiết kế pipeline nhưng lại có quá nhiều điểm đình trệ trong pipeline này. Chúng tôi có nhiều giai đoạn, nhưng không tối đa hóa throughput của tất cả các giai đoạn vì những bug thiết kế ngớ ngẩn gây ra độ trễ ở nhiều phần khác nhau. Độ trễ này là điều mọi người thường phàn nàn khi không thể gửi transaction hoặc khi nói hệ thống bị dao động. Sự dao động này không bắt nguồn từ bất cứ yếu tố nền tảng hay phần cứng nào—chỉ là chúng tôi đang xử lý mọi thứ chưa tối ưu.

Nhưng nói thật với bạn, những thứ chúng tôi làm đều ngớ ngẩn. Có một số bug cực kỳ rõ ràng và chúng tôi chỉ đang sửa những bug rõ ràng đó.

Anh quyết định khi nào những bug này cần micro-benchmark, khi nào cần phát lại toàn bộ lưu lượng mainnet bằng cách nào?

Tôi nghĩ phần lớn vấn đề hiệu năng của chúng tôi xuất phát từ việc mọi người viết micro-benchmark. Họ làm cho micro-benchmark nhanh hơn. Họ kiểm thử chúng một cách độc lập. Rồi khi ghép mọi thứ lại trong Agave, chẳng thứ gì hoạt động giống như micro-benchmark.

Vì vậy, cá nhân tôi nói với mọi người: tuyệt đối không dùng micro-benchmark cho bất cứ việc gì. Ngay cả việc phát lại transaction—đó là việc có lẽ tôi chỉ làm ba lần trong năm qua. Bởi ngay cả khi phát lại lưu lượng mainnet, bạn cũng không phát lại ở chính xác cùng tốc độ như khi thực sự thực thi lưu lượng mainnet, nên rất nhiều thứ thay đổi.

Và đây là một phần lý do chúng tôi đang giúp quá trình khởi động nhanh hơn rất nhiều, bởi nếu mỗi lần muốn xem bản sửa lỗi có hiệu quả hay không mà phải chờ nửa giờ thì rất phiền.

Khi đạt đến giai đoạn hiện tại của Agave, bạn không thể chỉ đào quá sâu vào một component duy nhất. Đó có thể là công việc thú vị về mặt trí tuệ, nhưng hoàn toàn vô dụng nếu không xem xét toàn bộ hệ thống. Nó không thực sự tạo ra tiến triển nào.

Vậy khi nhìn vào toàn bộ hệ thống, tại sao việc viết lại Turbine để sử dụng XDP lại quan trọng đến vậy?

Ngay trước khi đến Solana, tôi làm việc về mạng. Tôi ở một startup chuyên kiểm tra packet chuyên sâu. Về cơ bản, họ chặn toàn bộ lưu lượng đi vào một NIC, phân tích theo thời gian thực để ngăn các luồng độc hại rồi đưa lại vào kernel. Về cơ bản, chúng tôi đã viết toàn bộ stack TCP và UDP trong user space bằng Rust, Tokio và tất nhiên là XDP.

Khi tôi gia nhập Anza, rõ ràng đến một lúc nào đó chúng tôi sẽ cần dùng XDP. Khi Firedancer bắt đầu, họ nói: “Chúng tôi sẽ bắt đầu với bản triển khai Turbine bằng XDP,” và tôi bảo họ điều đó thật ngớ ngẩn. Nó chẳng hợp lý chút nào. Làm vậy tốn nhiều thời gian hơn vì xét một cách khách quan, XDP là một API tệ hại. Vì vậy, bạn muốn tránh dùng nó càng lâu càng tốt, cho đến khi hệ thống thực sự sụp đổ.

Rồi bạn sẽ nghĩ, ôi [đã biên tập], giờ mình phải dùng XDP, và đó chính là điều đã xảy ra với chúng tôi. Chúng tôi đã loại bỏ mọi nút thắt cổ chai khác trong pipeline cho đến ngày bắt đầu kiểm thử tải và thấy Turbine hoàn toàn ngừng hoạt động.

Vì vậy, chúng tôi nghĩ, được rồi, rõ ràng cách này không còn khả thi. Tôi thực sự đã cố hết sức để không dùng XDP vì từng sử dụng nó và biết nó kinh khủng đến mức nào. Tôi đã cố xây dựng một bản triển khai Turbine dựa trên io_uring. Sau đó tôi tìm thấy một số bug trong io_uring và bắt đầu sửa chúng. Tôi vẫn còn một số bản vá kernel muốn gửi, nhưng đến một lúc nào đó tôi nhận ra mình không thể yêu cầu mọi đơn vị vận hành validator sử dụng kernel tùy chỉnh của tôi để chạy Solana.

Tôi sẽ phải dùng XDP và chúng tôi đã làm vậy. Giờ nó hoạt động.

Câu trả lời là: bạn tìm nút thắt cổ chai tiếp theo rồi khắc phục nó. Và bạn tiếp tục khắc phục mọi nút thắt tìm thấy. Vấn đề của ngày mai có thể để ngày mai suy nghĩ. Đó là phương châm của tôi. Bạn có thể chỉ lo về ngày mai, nhưng như vậy hôm nay sẽ rất tệ. Hôm nay Solana đang rất tệ. Block quá nhỏ, Turbine gây ra quá nhiều độ trễ, scheduler vẫn còn vấn đề. Chúng ta phải khắc phục mọi thứ ngay hôm nay. Nếu không, sẽ chẳng có ngày mai để đạt đến tốc độ đó.

Anh ngăn chặn tình trạng suy giảm hiệu năng bằng cách nào? Anh phối hợp với Firedancer ra sao?

Suy giảm hiệu năng là một cuộc vật lộn. Cá nhân tôi profile thứ gì đó trong Agave mỗi ngày, ít nhất vài lần mỗi ngày, và chúng tôi thường gặp tình trạng suy giảm vì viết code có hiệu năng cao là cả một công việc. Bạn cần biết cách viết code có hiệu năng cao. Nếu viết code Rust, trung bình nó sẽ có hiệu năng cao hơn code Node.js, Python hay bất cứ thứ gì khác. Nhưng nếu làm việc với AccountsDB, nơi phải xử lý các collection có hàng triệu mục, bạn không thể chỉ đơn giản viết code. Việc xây dựng thuật toán và xử lý dataset lớn một cách hiệu quả rất khó.

Vì vậy, đôi lúc chúng tôi vẫn gặp tình trạng suy giảm. Cho đến khoảng một tháng trước, về cơ bản tôi cứ quát mọi người, haha. Chẳng hạn như Brooks với AccountsDB—tôi nghĩ có lúc anh ấy ghét tôi. Chúng tôi có mối quan hệ rất tốt, nhưng cho đến một tháng trước, về cơ bản một nửa số lần tương tác là tôi quát anh ấy vì thứ gì đó trong AccountsDB chạy chậm hơn.

Về giao thức, việc hợp tác với Firedancer đã cải thiện điều này vì tôi cảm thấy nhiều phần của giao thức cuối cùng đã phát triển tự nhiên để ứng phó với các thách thức khác nhau. Quá trình phát triển giao thức bắt đầu bằng một ý tưởng; họ đưa nó vào production và giống như hầu hết ý tưởng, nó không hoạt động ngay lần đầu. Sau đó, họ bắt đầu bổ sung thêm nhiều thứ bên trên. Xét về hiệu năng, nhiều thứ được thêm vào là những ý tưởng cực kỳ tệ.

Ví dụ, trong Gossip từng có một thứ gọi là epoch slots, về cơ bản cluster sẽ truyền cho mọi người thông tin validator của ai đã thấy những slot nào. Khoảng sáu tháng trước, khi tình cờ profile một thứ khác, tôi nhận thấy xét về CPU, epoch slots này tốn nhiều thời gian hơn cả việc thực sự thực thi transaction. Xét về băng thông, nó sử dụng lượng băng thông gấp bốn lần Turbine. Đây chỉ là một bản vá ngẫu nhiên từng được xây chồng lên giao thức để giảm nhẹ một vấn đề.

Vì vậy, điều này không còn xảy ra nữa. Và một phần là nhờ Firedancer. Giờ đây, khi ai đó đưa ra đề xuất, chúng tôi phải làm việc với Firedancer. Rõ ràng họ đang xây dựng một client khác, haha, nên phải phân bổ nguồn lực cho công việc. Họ phải quyết định sẽ mất bao lâu để triển khai đề xuất này. Mức độ ưu tiên của nó là gì? Vì vậy, dù tốt hay xấu, họ đều phản biện và phản biện rất nhiều, hoặc gần như tất cả thay đổi mà chúng tôi thực hiện. Họ rất giỏi trong việc phản đối những thay đổi thực sự tệ.

Sau khi Turbine được phát hành cùng XDP, nếu có một tháng không họp hành, không xung đột và hoàn toàn tự do làm bất cứ điều gì, phần đầu tiên của Agave mà anh sẽ tối ưu hoặc tái kiến trúc là gì?

Tôi thực sự muốn—tôi đúng nghĩa đã mơ về việc này—tôi muốn viết lại AccountsDB khoảng hai năm nay. Tôi chỉ biết rằng nếu bắt đầu làm, nó sẽ thực sự lấy đi một hoặc hai tháng cuộc đời tôi. Hiện tại, đó không phải cách tốt nhất để tôi sử dụng thời gian. Nhưng tôi sẽ làm. Tôi vẫn cố ép Brooks làm việc đó, nhưng nếu anh ấy không làm thì đến lúc nào đó tôi sẽ tự làm.

Những bước phát triển trong tương lai

Nhìn về tương lai với các tính năng đã được lên kế hoạch như Thực thi bất đồng bộ hoặc Nhiều leader đồng thời, đâu sẽ là vấn đề đau đầu nhất với đội hiệu năng?

Theo bản năng, tôi ghét bất đồng bộ. Mô hình hiện tại rất đơn giản. Bạn nhận một số transaction, phát lại chúng thật nhanh rồi bỏ phiếu. Về mặt khái niệm, nó cực kỳ dễ hiểu. Bất đồng bộ khiến thiết kế khó hơn, nhưng cũng giúp trải nghiệm thực tế khi sử dụng blockchain tốt hơn rất nhiều.

Tôi cũng ghét thiết kế Nhiều leader đồng thời, haha. Tôi hiểu rằng bạn cần nhiều leader, đặc biệt nếu muốn thực hiện giao dịch tốc độ cao. Không có phương án nào khác. Nhưng cá nhân tôi cho rằng điều đó sẽ không xảy ra trong ít nhất 12 tháng nữa. Vì vậy, tôi không muốn bị phân tâm quá nhiều.

Điều quan trọng là sau một năm chúng ta có Alpenglow, nhưng cũng quan trọng không kém là trong tháng tới chúng ta đạt một trăm triệu CU. Chúng ta cần tập trung làm cho những gì đang có hiện nay chạy nhanh, bởi Alpenglow là code mới và Nhiều leader đồng thời cũng là code mới. Có những điều chưa biết mà chúng ta còn không biết tới. Giả sử vì lý do nào đó Alpenglow bị chậm tiến độ như Firedancer. Rồi sao? Chúng ta cứ tiếp tục dùng blockchain tệ hại, chậm chạp hiện nay à? Không, chúng ta phải tập trung chạy nhanh ngay hôm nay.

Lời khuyên về kỹ thuật hiệu năng

Anh đề xuất những tài nguyên nào cho người có kinh nghiệm Rust muốn tìm hiểu về lập trình hiệu năng và profiling?

Trước hết, tôi khuyên dùng một profiler tốt, thứ hiện nay chưa tồn tại, haha. Nhưng hy vọng tôi sẽ sớm phát hành profiler của mình. Và tôi thực sự nghĩ cách tốt nhất để học bất kỳ điều gì là thực hành trên thứ mà bạn thật sự quan tâm.

Vì vậy, lời khuyên của tôi dành cho những người muốn học cách làm việc về hiệu năng là hãy tìm một phần mềm bạn sử dụng hằng ngày và yêu thích, profile nó rồi khiến nó nhanh hơn, bởi rất nhiều phần mềm chạy rất chậm. Ngay cả nhiều phần mềm vốn đã nhanh vẫn có thể nhanh hơn rất nhiều. Máy tính thực sự rất nhanh. Và chính vì chúng rất nhanh, bạn có thể dễ dàng làm ra thứ gì đó chậm mà thậm chí không hề nhận ra.

Theo những gì tôi thấy, cách khiến nhiều người bị cuốn vào là tìm một thứ bạn sử dụng rồi profile nó—làm cho nó nhanh hơn, gửi pull request và tôi bảo đảm chúng sẽ được chấp nhận. Bạn sẽ mê mẩn việc đó.

Kernel cũng chỉ là một dependency như bao dependency khác. Khi làm việc với thứ gì đó và sử dụng một thư viện, rất có thể đến một lúc nào đó bạn phải tìm hiểu bên trong thư viện nếu có thứ không hoạt động, chạy chậm hay gặp bất kỳ vấn đề gì. Kernel chỉ là một thư viện khác. Vì vậy,, hãy đọc code kernel. Code kernel là một trong những loại code đơn giản nhất tôi từng thấy. Nếu nhìn vào scheduler trong kernel, về mặt khái niệm nó đơn giản hơn scheduler chúng ta có trên Solana.

Cứ đọc code Linux đi. Đó là C, không lý tưởng, và bất cứ thứ gì động đến phần cứng thường đều đáng nguyền rủa, haha, nhưng phần lớn Solana không làm việc trực tiếp với phần cứng. Nếu tìm thấy những thứ phổ biến mà bạn dùng hằng ngày, như syscall, Tokio hoặc code hệ thống tệp, thì chúng rất dễ hiểu. Cứ đọc đi. Nếu dành một tuần đọc, bạn sẽ hiểu nó như mọi code khác. Và bạn sẽ cảm thấy mình đúng là một thiên tài chết tiệt. Bạn sẽ nghĩ, à, giờ mình có thể làm việc với kernel rồi, hiểu chứ?

Cách tốt nhất để bắt đầu đóng góp ngay hôm nay là gì?

Tôi thích mọi người vào Discord và tham gia kênh phát triển của Solana Tech Discord. Ví dụ, có một người đang làm một số việc về mạng, hôm nọ anh ấy vừa bắt đầu một cuộc trò chuyện về code TPU. Thành thật mà nói, anh ấy hiểu cách code đó hoạt động rõ hơn phần lớn người tại Anza. Bạn hoàn toàn có thể đóng góp. Và nếu giỏi như người đó rồi gửi bản vá cho tôi, tôi sẽ hợp nhất chúng.

Chúng tôi không thực hiện nhiều hoạt động phát triển nội bộ, không công khai. Vì vậy, nếu bạn không thấy pull request nào trong một đoạn code mà mình cho là chậm, có hiểu biết về nó,, và muốn sửa, hãy nói với tôi trên Discord. Chúng tôi sẽ tạo issue, giao nó cho bạn và bạn sẽ sửa nó.

Tôi muốn mọi người gửi bản vá cho mình. Tôi thực sự muốn phát triển cộng đồng thông qua việc gửi bản vá.

Câu hỏi nhanh

Bug khó nhất mà anh đã xử lý trong năm nay là gì?

Một lỗi biên dịch sai với một số code dấu phẩy động đã cản trở bản phát hành 2.2 chỉ vài tháng trước. Nó không phải lỗi khó nhất, nhưng là thứ tẻ nhạt nhất vì tôi phải dành nhiều ngày chỉ để đọc code assembly.

Anh nghe đi nghe lại loại nhạc nào khi nhìn vào flame graph?

Thường là house hoặc minimal techno. Tôi thường phát Stephan Bodzin lặp đi lặp lại.

Bản phân phối Linux yêu thích của anh là gì?

Chắc chắn là Debian. Đây là bản duy nhất không quá phiền phức, haha.

Tối ưu hóa tốt nhất sắp xuất hiện cùng Alpenglow là gì?

Đó là chúng tôi sẽ không thực thi phiếu bầu. Transaction bỏ phiếu thật [đã biên tập]. Và thật tuyệt khi toàn bộ việc bỏ phiếu không còn là transaction nữa.

Anh nghĩ gì về ZK?

Đây là một công nghệ tuyệt vời, nhưng tôi cảm thấy nó vẫn đang chủ yếu ở giai đoạn nghiên cứu đối với việc mở rộng blockchain. Vì vậy, tôi không quá quan tâm.

Tháng 7 năm 2026, tức một năm nữa, anh dự đoán thời gian slot sẽ là bao nhiêu?

Cá nhân tôi muốn có slot 200 mili giây, hy vọng là còn sớm hơn thời điểm đó. Tôi liên tục nói với Toly rằng anh ấy cần biến nó thành meme để hiện thực hóa. Vì vậy, hy vọng đến lúc đó điều này sẽ xảy ra. Tôi nghĩ ngay hôm nay chúng ta cũng có thể làm được. Tôi nghĩ đó sẽ là mức tối thiểu, theo nghĩa bất cứ mức nào cao hơn đều là thất bại, nhưng chúng ta có thể xuống thấp hơn nữa.

Khi nào Agave sẽ đạt mốc 1 triệu TPS định mệnh đó?

Haha, câu này tôi sẽ không trả lời nhanh đâu. Tôi liên tục hỏi mọi người: “Một triệu transaction đó sẽ đến từ đâu?”

Chúng ta sẽ đạt một triệu TPS khi mọi người có một triệu TPS để gửi, nhưng đáng buồn là tôi không nghĩ điều đó sẽ sớm xảy ra. Tôi từng nói nếu Agave không đạt một triệu TPS vào tháng 10, tôi sẽ nghỉ việc. Vì vậy, có lẽ tôi sẽ phải bịa ra một bản demo, haha.

Kết luận

Alessandro Decina đại diện cho trái tim đang đập của văn hóa hiệu năng tại Solana—một hành trình theo đuổi tốc độ không ngừng nghỉ, dựa trên kỹ thuật thực dụng thay vì sự hoàn hảo về lý thuyết. Đội hiệu năng của anh tạo ra tác động vượt xa quy mô của mình khi tìm và sửa những “bug ngớ ngẩn” cộng dồn lại thành tình trạng chậm trên toàn hệ thống.

Trong một thế giới mà nhiều đội ngũ lạc lối trong những tầm nhìn kiến trúc vĩ đại, đội hiệu năng của Anza vẫn tập trung tuyệt đối vào các nút thắt cổ chai ngay trước mắt. Profile, xác định, khắc phục, lặp lại. Đó là công việc không hào nhoáng nhưng mang lại kết quả ấn tượng: một blockchain thực sự mở rộng theo phần cứng, thay vì xoay xở xung quanh giới hạn của nó.

Cuộc trò chuyện trên cho thấy một sự thật nền tảng về việc xây dựng hệ thống hiệu năng cao: tốc độ không chỉ đến từ thuật toán thông minh hay phần cứng tiên tiến. Nó còn đến từ cam kết văn hóa không bao giờ chấp nhận mức “đủ tốt” khi về mặt kỹ thuật có thể đạt đến mức “xuất sắc”. Với Solana, điều đó có nghĩa slot 200 mili giây, Thực thi bất đồng bộ, Nhiều leader đồng thời và duy trì hơn một triệu TPS không chỉ là các cột mốc kỹ thuật—chúng là những điều tất yếu.