Kecepatan Rekayasa: Menilik Tim Performa Anza bersama Alessandro Decina

Pendahuluan

Tekno-optimisme tidak diragukan lagi merupakan semangat budaya Solana. Keyakinan tanpa batas pada kecepatan, kemajuan, dan inovasi melandasi setiap pull request yang dikirim ke mainnet. Mantranya adalah IBRL: Increase Bandwidth, Reduce Latency. Ini sekaligus merupakan titah rekayasa, semboyan budaya, dan doa sekuler. Jika Bitcoin adalah katedral bagi keabadian, dan Ethereum adalah agora bagi netralitas, Solana adalah sirkuit balap: ranah kecepatan mekanis yang dapat diukur.

Namun, kecepatan ini tidak pernah turun begitu saja dari langit dalam bentuk diff yang diberi komentar dengan rapi. Kecepatan ini ditambang, diasah, dan diwujudkan oleh mereka yang berani menatap kode sepanjang hari. Hanya sedikit yang menatap lebih keras daripada Alessandro Decina, yang awalnya merupakan pakar GStreamer dan menganggap buffer video yang tersendat sebagai penghinaan pribadi. Kini, ia memimpin tim performa Anza yang beranggotakan empat orang, sebuah tim yang menganggap menghapus bilah kuning dari trace validator pada pukul 3 pagi sebagai bentuk “perawatan diri”. Keseharian mereka diisi dengan menatap flame graph, membongkar seluruh alur kerja, dan menulis ulang kode produksi yang telah teruji karena apa pun yang dapat dioptimalkan pada akhirnya akan dioptimalkan.

Saya ingin memahami seperti apa hidup dengan kecepatan ini. Jadi, saya berbincang langsung dengan Alessandro Decina untuk mengetahui bagaimana ia terus membuat blockchain tercepat yang pernah ada menjadi lebih cepat lagi. Wawancara berikut adalah autopsi atas kecepatan. Kami membahas masa-masanya bekerja dengan pipeline multimedia hingga pagar pembatas budaya yang memungkinkan empat engineer mengirimkan lebih banyak hasil daripada seluruh organisasi. 

Percakapan ini telah diedit dan diringkas agar lebih jelas dan singkat.

Wawancara

Awal Mula dan Cara Pandang

Ichigo: Mari mengenang masa lalu. Cinta pertama Anda adalah GStreamer dan pipeline multimedia. Apa pelajaran terbesar tentang latensi dari masa itu? Apa yang Anda pelajari dari mengejar audio dan video real-time untuk memangkas beberapa milidetik dari Agave? 

Decina: Pertama-tama, hebat juga Anda menguntit saya, haha. Saya bekerja pada GStreamer selama sekitar 15 tahun—mungkin sedikit lebih lama. Di sanalah saya benar-benar mempelajari semua yang saya ketahui. Saya mulai berkontribusi pada proyek tersebut saat masih open source dan baru dirintis. Saya sangat beruntung karena bisa dekat dengan pendirinya saat itu. Orang itu, entahlah, sekitar 15 tahun lebih tua dari saya, dan dia sangat hebat. Maksud saya, orang ini ada di Wikipedia—dia mungkin pintar. Tidak seperti saya—saya hanya berpura-pura pintar. Dia begitu saja memutuskan, ya, terserah, saya akan mengajarkan semua yang saya tahu kepada Anda secara gratis. Jadi, ya, saya pun mulai mengerjakannya.

Lucu rasanya sekarang kita membicarakan latensi rendah saat mengerjakan Solana, karena ini sama sekali bukan latensi rendah. Saat Anda berbicara tentang pemrosesan audio, DPS, dan perangkat keras multimedia, hal-hal yang kita lakukan di Solana memiliki latensi yang sangat tinggi. Jika audio atau video memiliki waktu respons 400 milidetik, pada dasarnya itu sudah rusak. Itu tidak akan berfungsi.

Pada satu titik, saya mulai bekerja dengan driver Linux dan perangkat keras yang melakukan encoding serta decoding video dan audio. Banyak hal yang saya lakukan saat ini pada dasarnya sama dengan yang saya lakukan pada masa itu. Saat bekerja dengan perangkat keras, latensi berarti ada antrean di suatu tempat. Anda mencari antrean itu. Anda mencoba meminimalkannya, membuatnya sekecil mungkin, dan memastikan antrean itu tidak pernah kehabisan data.

Misalnya, pekerjaan XDP yang saya lakukan sekarang sangat mirip dengan cara kerja ring buffer audio. Bahkan dalam panggilan yang sedang kita lakukan sekarang, ada sekumpulan paket yang tiba tidak berurutan. Ada ring buffer di suatu tempat yang mengurutkan ulang semua paket, dan Anda tentu ingin memastikan buffer itu tidak kehabisan data.

Rasanya saya telah mengerjakan hal yang sama selama 20 tahun terakhir.

Bisa dibilang, hal yang sama di hari yang berbeda. Karena saya juga melihat Anda pernah bekerja di Spotify, dan ada sedikit kaitannya dengan Firefox—

Ahh, tidak, pekerjaan Firefox itu hanya pekerjaan integrasi untuk sebuah hackathon. Haha, saya sudah sangat tua sampai-sampai saya menulis tag video asli untuk Firefox yang menggunakan GStreamer.

Astaga, haha. Jadi semua jalan kembali menuju GStreamer? 

GStreamer benar-benar mengajari saya pemrograman multi-threaded. Itulah alasan saya berada di ekosistem ini. Ada orang-orang yang menulis Assembly dan melakukan berbagai trik tingkat rendah. Saya seperti, ya, saya sudah lama melakukan itu. Dan saya belajar bahwa kecuali Anda memiliki bahasa dengan sistem tipe yang kuat dan compiler yang bagus, Anda akhirnya akan mencelakai diri sendiri. Saya yakin Anda bisa membuat sesuatu sedikit lebih cepat dengan Assembly, tetapi saya benar-benar menginginkan Rust. 

Saya ingin compiler Rust memberi tahu saya: Anda bodoh—ini tidak akan berfungsi karena ada bug di sini. Sebelum Rust, saya merasa 10% diri saya adalah software engineer dan 90% sisanya debugger berdaging. Saya hanya sibuk melakukan debugging. Jadi, menurut saya GStreamer dan kecintaan saya pada Rust adalah alasan saya mulai bekerja pada Solana. Rust mulai populer, belum banyak pekerjaan yang memungkinkan Anda menggunakannya penuh waktu, dan saya telah memutuskan bahwa saya hanya akan bekerja dengan Rust. 

Saya terlalu tua untuk menulis C. Saya tidak menginginkan bahasa yang tidak aman dari sisi memori. Saya tidak mau membuang waktu. Jadi, ya, di sinilah saya sekarang.

Bagus sekali. Jadi, saat beralih, apakah Anda memiliki kesalahpahaman tentang sistem terdesentralisasi sebelum mengerjakan kode validator? Apa yang meyakinkan Anda bahwa arsitektur Solana benar-benar dapat diskalakan? 

Pada akhirnya, saya bergabung dengan Solana hampir dua tahun terlambat karena sibuk mengerjakan compiler Rust. Seseorang di Solana yang baru mulai mengerjakan virtual machine mengirim email dan berkata, “Oh, saya mengerjakan hal yang sama. Sepertinya Anda sedikit lebih maju, bergabunglah dengan kami.” Saya tidak membalas email itu karena saya mempelajari Bitcoin lalu Ethereum, dan menyadari bahwa Anda memang dapat mengeksekusi sesuatu, tetapi hanya memiliki 10 TPS. Itu bukan proyek yang serius, bukan? Anda tidak dapat melakukan hal nyata apa pun dengan 10 TPS. 

Jadi, ketika menerima email itu, saya tidak membalas. Saya hanya berpikir, baiklah, orang-orang kripto ini belum serius.

Toly menghubungi saya dua tahun kemudian, dan saya memeriksa harga SOL. Saya berpikir, baiklah, seharusnya saya membuka email itu, haha. Kali ini saya akhirnya berbincang dengannya. Sebelum berbincang, dia menunjukkan beberapa kode kepada saya. Saya melihatnya dan, sejujurnya, kodenya buruk sekali. Ini benar-benar kode Rust yang sangat buruk.

Namun, kemudian saya berbicara dengan Toly tanpa mencarinya di Google, jadi saya sama sekali tidak tahu siapa dia. Dia pintar dan mengatakan semua hal yang tepat. Dia berkata bahwa kami sedang membangun sesuatu. Saat ini, kami melakukan ini. Jelas belum mutakhir, tetapi ambisinya adalah agar kami berkembang seiring perangkat keras. Kami membangun blockchain dengan performa tertinggi, lalu perangkat keras menjadi hambatannya. Gagasannya adalah makin banyak perangkat keras yang Anda berikan kepada sistem ini, makin besar skalanya.

Dan itu meyakinkan saya. Rasanya ini bukan sekadar sekelompok maniak blockchain yang berfantasi tentang Perang Dunia III…Saya tertarik pada teknologinya. Saya adalah salah satu dari sedikit orang kripto yang benar-benar berada di sini demi teknologinya.

Solana memiliki budaya rekayasa dengan teknologi yang sangat dipengaruhi oleh tekno-optimisme—seluruh budaya Increase Bandwith, Reduce Latency itu. Bagaimana Anda memandangnya secara pribadi? Bagaimana hal tersebut memengaruhi keseharian di Anza? 

Bagi saya, Ethereum pada dasarnya memiliki pola pikir kelangkaan. Mereka seperti, baiklah, kita telah menabrak beberapa tembok dan akan mencari jalan memutar untuk mengatasinya. Kita akan menciptakan seluruh infrastruktur ini demi sesuatu yang pada dasarnya merupakan kesenjangan pengetahuan yang kita miliki dan kita rasa mustahil untuk diperbaiki, bukan?

Sebaliknya, saya merasa kita adalah kebalikannya. Kurang lebih begini, baiklah, ada masalah. Tidak ada masalah yang tidak dapat diselesaikan, selain hal-hal yang melanggar hukum fisika. Ini hanyalah perbedaan budaya yang sangat besar.

Jika ada sesuatu yang rusak, kami hanya berkata, baiklah, mari duduk bersama. Mari lakukan profiling dan melihat masalahnya. Mari berbicara dengan trader dan market maker. Mari melihat masalah mereka. Belakangan ini, kami menemukan beberapa masalah yang sangat konkret. Dan kami telah memperbaiki sebagian besarnya. Sejujurnya, dalam dua hingga tiga bulan, kami dapat memperbaiki semuanya. 

Ada banyak hal yang saat ini tidak berfungsi di Solana. Kami mengetahuinya, dan kami tidak pernah duduk lalu berkata, “Kami memiliki solusi sempurna! Dan sekarang, untuk melangkah lebih jauh, kami perlu menciptakan sesuatu yang baru, atau harus melakukan riset dan hal lain.” Tidak—ini adalah masalah konkret. Sebagian besar merupakan masalah yang benar-benar bodoh. 

Dan, belakangan ini kami tidak mengalami outage. Secara pribadi, menurut saya itu pertanda bearish, bukan? Karena saya pikir sebagian orang mulai sedikit konservatif. Kami tahu kami dapat melaju jauh lebih cepat. Kami tahu kami dapat menjalankan block 100 juta CU besok, bukan? Kami hanya perlu melakukan beberapa hal secepat mungkin. Dan saya mendukung percepatan segala hal.

Pada dasarnya kami tahu—kami tidak memerlukan roadmap untuk mengetahui bahwa kami dapat meningkatkan performa saat ini 10 kali lipat. Kami tahu cara melakukannya. Kami telah menulis kodenya tetapi belum sepenuhnya selesai, atau kami telah menulis kodenya tetapi tidak dapat men-deploy-nya karena masih ada beberapa edge case yang perlu diperbaiki. Namun, kami tahu persis apa yang harus dilakukan.

Kami tahu cara menskalakan sistem ini.

Rekayasa Performa

Berbicara tentang pekerjaan performa, menurut saya tidak banyak orang yang benar-benar tahu bahwa Anza memiliki tim performa khusus. Tim ini seperti luput dari perhatian. Ceritakan sedikit tentang struktur tim tersebut. Apa perbedaannya dengan tim engineering lain di Anza? 

Benar, kami memang memiliki beberapa tim berbeda di Anza. Saat ini ada tim konsensus yang berfokus pada Alpenglow. Ada tim jaringan yang sebagian besar berfokus pada Gossip. Ada tim AccountsDB yang pada dasarnya hanya mengerjakan database account. Ada tim produksi block yang mengerjakan scheduler. Dan tentu saja, semua tim lain yang saya lupakan.

Perbedaan tim performa adalah kami mengerjakan semuanya. Kami melakukan profiling, menemukan bottleneck, lalu mencoba menanyakan kepada tim terkait apakah mereka memiliki waktu dan keahlian karena terkadang kami menemukan masalah yang tidak dapat diperbaiki oleh semua orang. Misalnya, jika Anda bekerja di bidang konsensus, belum tentu Anda paling ahli dalam pemrograman tingkat rendah karena keahlian Anda berada di bidang lain. Jadi, dalam kasus seperti itu, biasanya kami turun tangan dan memperbaiki kode untuk mereka.

Jadi, kami tidak hanya mengerjakan satu hal. Kami mencari bottleneck berikutnya. Kami melakukan sinkronisasi kira-kira setiap dua minggu dan menentukan posisi kami, apa yang perlu dilakukan selanjutnya, serta bagaimana membuat rilis berikutnya lebih cepat.

Perbedaan besar lainnya adalah Anza cenderung merekrut orang-orang pintar. Misalnya, jika Anda tidak menguasai Rust, tidak masalah. Jika Anda tidak menguasai pemrograman tingkat rendah, tidak masalah. Kami berasumsi bahwa jika Anda pintar, kami dapat mengajarkan sebagian besar keterampilan ini saat bekerja. Untuk tim performa, saya biasanya merekrut orang yang benar-benar berpengalaman dengan kernel atau hal tingkat rendah lainnya karena jenis bottleneck yang sedang kami hadapi saat ini.

Misalnya, pada database account, ada beberapa masalah algoritmis yang harus kami perbaiki. Tetapi*,* alasan database account dalam rilis 2.3 menjadi sekitar sepuluh kali lebih cepat dibandingkan dua bulan lalu adalah karena kami memperbaiki cara kerjanya dalam melakukan I/O. Anda perlu mengetahui cara kerjanya untuk membuatnya lebih cepat. Jika Anda hanya memiliki pemahaman tingkat tinggi tentang database, Anda tidak benar-benar mengetahui cara kerja disk dan tidak perlu mengetahui cara kernel menjadwalkan permintaan I/O.

Jadi, secara pribadi, untuk tim performa, saya cenderung merekrut lebih banyak orang dengan keahlian tingkat rendah. Sekali lagi, saya bahkan tidak peduli apakah mereka menguasai Rust, tetapi saya ingin mereka pernah bekerja dengan C atau C++ pada hal-hal tingkat rendah lainnya.

Alasan keberadaan tim performa tidak begitu diketahui adalah karena pada dasarnya kami baru memulainya pada Desember. Awalnya saya direkrut untuk mengerjakan compiler, tetapi beralih ke performa sekitar outage pada Maret 2024 dan mulai mengoptimalkan berbagai hal. Orang-orang tidak terlalu senang karena suatu hari saya tiba-tiba mengatakan bahwa saya akan mengerjakan apa pun yang saya inginkan. Jadi, ya, haha, mereka tidak senang, tetapi kemudian kami mendapatkan hasil yang sangat bagus. Lalu orang-orang mendatangi saya dan berkata, “Baiklah, sebenarnya, apakah Anda ingin merekrut lebih banyak orang untuk melakukan ini?” Kemudian pada Desember, kami meresmikan upaya performa dan membentuk tim.

Sejujurnya, saya memang bias, tetapi tim performa adalah tim terbaik di Anza, tidak diragukan lagi.

Saya tidak meragukannya, haha. Berapa jumlah anggota timnya? 

Kami berempat bekerja penuh waktu, tetapi saya sering bercanda di Twitter tentang Brooks dan beberapa orang lain yang bergabung karena saya mulai membagikan profiler saya secara lebih luas. Hingga sekitar dua bulan lalu, hanya tim performa yang memiliki akses ke profiler tersebut. Sekarang semua orang memilikinya. Misalnya Brooks, sejak saya memberinya profiler, Brooks melakukan lebih banyak pekerjaan performa daripada saya, haha. Dia benar-benar ketagihan. Sekarang dia membuat semuanya menjadi lebih cepat.

Jadi, secara tidak resmi kini ada Brooks dan beberapa orang lain yang juga banyak mengerjakan hal terkait performa. Namun, kami berempat bekerja penuh waktu pada performa. 

Jadi, saat mengerjakan performa, apa “tanda mencurigakan” yang Anda cari ketika melakukan profiling dan mungkin terlewat oleh sebagian besar engineer? Bagaimana Anda menentukan apa yang perlu dioptimalkan? 

Ada beberapa hal yang sangat jelas. Saat pertama kali melakukan profiling pada Agave, kami menghabiskan jauh lebih banyak waktu di dalam kernel daripada mengeksekusi kode user space, dan itu tidak masuk akal. Kami bukan aplikasi tingkat rendah. Jika kami adalah framework multimedia, masuk akal jika sebagian besar pekerjaan dilakukan di kernel karena pada akhirnya Anda perlu mengirim sampel ke perangkat keras. Namun, satu-satunya pekerjaan yang benar-benar bersifat tingkat rendah bagi kami adalah Turbine.

Jadi, biasanya tanda mencurigakan terbesar ketika saya mulai melakukan profiling adalah jika saya melihat banyak warna kuning di flame graph karena itu berarti kami menghabiskan terlalu banyak waktu di kernel. Kemungkinan ada seseorang yang menggunakan API tingkat tinggi yang terlihat tidak berbahaya, tetapi di balik layar performanya sangat buruk.

Dalam setahun terakhir, kami telah mengurangi jumlah memori yang digunakan Agave sekitar 10 kali lipat karena biasanya kami menghadapi masalah yang sama. Saat melakukan terlalu banyak alokasi memori, pada titik tertentu Anda perlu mulai berinteraksi dengan kernel. Anda dapat melihat interaksi dengan kernel di profiler. Anda melihat, baiklah, dari mana asalnya? Anda melihat bahwa rantai ini terus-menerus menguras memori. Anda melacaknya sampai ke titik tempat terlalu banyak memori digunakan dan dialokasikan, lalu memperbaikinya.

Ada beberapa hal yang lebih sulit. Misalnya, ada masalah desain mendasar yang kami temukan dan sedang saya perbaiki. Seperti yang banyak diketahui, Solana menggunakan pipeline dan memiliki berbagai tahap. Semuanya seharusnya diparalelkan agar berjalan secara paralel.

Dalam praktiknya, karena cara arsitekturnya dibangun, kami memang memiliki desain pipeline, tetapi ada begitu banyak stall dalam pipeline ini. Jadi, kami memang memiliki berbagai tahap, tetapi tidak memaksimalkan throughput semua tahap akibat bug desain bodoh yang menimbulkan latensi di berbagai bagian. Latensi inilah yang biasanya dikeluhkan orang ketika mereka tidak dapat mengirim transaction atau ketika mengatakan ada jitter dalam sistem. Jitter ini bukan disebabkan oleh sesuatu yang mendasar atau oleh perangkat keras—kami hanya menjalankan berbagai hal dengan cara yang tidak optimal. 

Namun, sejujurnya, jenis hal yang kami kerjakan itu bodoh. Ada beberapa bug yang sangat jelas, dan kami hanya memperbaiki bug yang jelas tersebut.

Bagaimana Anda menentukan apakah bug ini memerlukan micro-benchmark atau perlu memutar ulang seluruh traffic mainnet? 

Menurut saya, sebagian besar masalah performa yang kami alami muncul karena orang-orang menulis micro-benchmark. Mereka membuat micro-benchmark menjadi lebih cepat. Mereka mengujinya secara terpisah. Lalu, ketika semuanya digabungkan dalam Agave, tidak ada yang berfungsi seperti micro-benchmark.

Jadi, secara pribadi saya memberi tahu orang-orang: jangan gunakan micro-benchmark untuk apa pun. Bahkan memutar ulang transaction—itu mungkin baru tiga kali saya lakukan selama setahun terakhir. Karena sekalipun Anda memutar ulang traffic mainnet, Anda tidak memutarnya pada kecepatan yang persis sama seperti ketika benar-benar mengeksekusi traffic mainnet, sehingga banyak hal berubah. 

Dan inilah salah satu alasan kami membuat startup jauh lebih cepat. Jika tidak, Anda harus menunggu setengah jam setiap kali ingin melihat apakah perbaikan Anda berhasil, dan itu menjengkelkan.

Ketika mencapai tahap seperti yang kami alami dengan Agave, Anda tidak dapat menyelami terlalu dalam hanya untuk satu komponen. Pekerjaan itu mungkin menarik secara intelektual, tetapi sama sekali tidak berguna tanpa mempertimbangkan keseluruhan sistem. Itu tidak benar-benar menghasilkan kemajuan apa pun. 

Jadi, ketika melihat keseluruhan sistem, mengapa penulisan ulang Turbine untuk menggunakan XDP menjadi hal yang begitu penting? 

Saya mengerjakan jaringan tepat sebelum bergabung dengan Solana. Saya bekerja di sebuah startup yang melakukan deep packet inspection. Jadi, pada dasarnya mereka mencegat seluruh traffic yang masuk ke NIC, menganalisisnya secara real-time untuk menghentikan aliran berbahaya, lalu memasukkannya kembali ke kernel. Pada dasarnya kami telah menulis seluruh stack TCP dan UDP di user space menggunakan Rust, Tokio, dan tentu saja XDP.

Saat bergabung dengan Anza, sudah jelas bahwa pada titik tertentu kami perlu menggunakan XDP. Ketika Firedancer dimulai, mereka berkata, “Kami akan memulai dengan implementasi XDP untuk Turbine,” dan saya mengatakan itu bodoh. Itu tidak masuk akal. Pengerjaannya membutuhkan waktu jauh lebih lama karena secara objektif XDP adalah API yang buruk. Jadi, Anda sebaiknya menghindari penggunaannya selama mungkin hingga rodanya benar-benar terlepas.

Kemudian Anda berkata, oh [disensor], sekarang saya harus menggunakan XDP, dan itulah yang terjadi kepada kami. Kami telah berupaya menghapus semua bottleneck lain dalam pipeline sampai pada hari ketika kami memulai load test dan melihat Turbine benar-benar berhenti berfungsi.

Jadi, kami berpikir, baiklah, ini jelas sudah tidak layak. Dan saya benar-benar berusaha sangat keras untuk tidak menggunakan XDP karena pernah menggunakannya dan tahu betapa buruknya itu. Saya mencoba membuat implementasi Turbine berbasis io_uring. Lalu saya menemukan beberapa bug di io_uring. Saya mulai memperbaiki bug tersebut. Saya masih memiliki beberapa patch kernel yang ingin saya kirimkan, tetapi pada satu titik saya menyadari, baiklah, saya tidak dapat menyuruh semua operator validator kami menggunakan kernel khusus buatan saya untuk menjalankan Solana.

Saya harus menggunakan XDP, dan kami pun melakukannya. Sekarang itu berfungsi.

Jawabannya adalah: Anda menemukan bottleneck berikutnya, lalu memperbaikinya. Dan Anda terus memperbaiki semua bottleneck yang ditemukan. Anda dapat memikirkan masalah besok pada hari esok. Itulah moto saya. Anda bisa saja hanya mencemaskan hari esok, tetapi hari ini akan terasa buruk. Kondisi Solana hari ini memang buruk. Block terlalu kecil, Turbine menambah terlalu banyak latensi, dan scheduler masih bermasalah. Kami harus memperbaiki berbagai hal hari ini. Jika tidak, tidak ada hari esok untuk melaju secepat itu.

Bagaimana Anda mencegah regresi performa? Bagaimana Anda berkoordinasi dengan Firedancer? 

Regresi performa adalah tantangan. Secara pribadi, saya melakukan profiling pada sesuatu di Agave setiap hari, setidaknya beberapa kali sehari, dan kami sering mengalami regresi karena menulis kode berperforma tinggi adalah sebuah pekerjaan tersendiri. Anda perlu mengetahui cara menulis kode berperforma tinggi. Jika Anda menulis kode Rust, rata-rata performanya akan lebih tinggi daripada kode Node.js, Python, atau apa pun. Namun, jika Anda, misalnya, mengerjakan AccountsDB yang menggunakan collection berisi jutaan item, Anda tidak bisa sekadar menulis kode. Membuat algoritma dan memproses dataset besar secara efisien itu sulit. 

Jadi, sesekali kami memang mengalami regresi. Hingga sekitar sebulan lalu, pada dasarnya saya hanya meneriaki semua orang, haha. Misalnya Brooks dengan AccountsDB—saya rasa pada satu titik dia membenci saya. Hubungan kami sangat baik, tetapi sampai sebulan lalu, sekitar separuh interaksi kami pada dasarnya diisi dengan saya meneriakinya karena ada sesuatu yang menjadi lebih lambat di AccountsDB.

Untuk protokol, bekerja dengan Firedancer telah memperbaiki hal ini karena saya merasa banyak bagian protokol pada akhirnya berkembang secara organik sebagai respons terhadap berbagai tantangan. Pengembangan protokol dimulai dengan sebuah gagasan; mereka menerapkannya ke produksi, dan seperti kebanyakan gagasan, itu tidak berhasil pada percobaan pertama. Kemudian mereka mulai menambahkan berbagai hal di atasnya. Dari sisi performa, banyak hal yang ditambahkan tersebut merupakan gagasan yang sangat buruk.

Misalnya, di Gossip, ada sesuatu yang disebut epoch slots, tempat cluster pada dasarnya menyiarkan kepada semua orang validator milik siapa yang telah melihat slot tertentu. Dan sekitar enam bulan lalu, ketika sedang melakukan profiling pada hal lain, saya menyadari bahwa dari sisi CPU, epoch slots ini memakan lebih banyak waktu daripada mengeksekusi transaction. Dari sisi bandwidth, penggunaannya empat kali lipat dari bandwidth yang digunakan Turbine. Ini hanyalah patch acak yang pada satu titik dibangun di atas protokol untuk memitigasi suatu masalah.

Jadi, hal ini tidak terjadi lagi. Dan sebagian berkat Firedancer. Sekarang, ketika seseorang mengajukan proposal, kami harus bekerja bersama Firedancer. Mereka tentu saja membuat client lain, haha, jadi mereka harus mengalokasikan pekerjaan. Mereka harus menentukan berapa lama waktu yang dibutuhkan untuk menerapkan proposal ini. Apa prioritasnya? Jadi, entah hasilnya baik atau buruk, mereka memberikan penolakan terhadap banyak, atau hampir semua, perubahan yang kami buat. Dan mereka sangat pandai menolak perubahan yang benar-benar buruk. 

Setelah Turbine diluncurkan dengan XDP, jika Anda memiliki satu bulan tanpa rapat dan tanpa konflik, dengan kebebasan penuh untuk mengerjakan apa pun, bagian Agave mana yang pertama kali akan Anda optimalkan atau rancang ulang arsitekturnya? 

Saya benar-benar ingin—saya sampai memimpikannya—menulis ulang AccountsDB sejak sekitar dua tahun lalu. Saya hanya tahu bahwa jika mulai melakukannya, itu benar-benar akan menyita satu atau dua bulan hidup saya. Dan saat ini, itu bukan cara terbaik bagi saya untuk menggunakan waktu. Namun, saya akan melakukannya. Saya terus mencoba mendesak Brooks agar melakukannya, tetapi jika dia tidak melakukannya, saya akan melakukannya sendiri pada suatu saat nanti.

Pengembangan di Masa Mendatang

Menatap masa depan dengan fitur yang direncanakan seperti Async Execution atau Multiple Concurrent Leaders, apa yang akan menjadi masalah terbesar bagi tim performa? 

Secara naluriah, saya membenci async. Modelnya saat ini sangat sederhana. Anda menerima beberapa transaction, memutarnya ulang dengan sangat cepat, lalu memberikan vote. Secara konsep, ini sangat mudah. Async membuat desainnya lebih sulit, tetapi juga membuat pengalaman nyata dalam menggunakan chain menjadi jauh lebih baik.

Saya juga membenci desain Multiple Concurrent Leaders, haha. Saya memahami bahwa khususnya jika ingin melakukan high-speed trading, Anda memerlukan beberapa leader. Tidak ada alternatif. Namun, secara pribadi, itu tidak akan terjadi setidaknya selama 12 bulan. Jadi, saya tidak ingin terlalu terdistraksi.

Penting bagi kita untuk memiliki Alpenglow dalam satu tahun, tetapi juga penting bagi kita untuk mencapai seratus juta CU dalam sebulan ke depan. Kita harus berfokus membuat apa yang kita miliki sekarang menjadi cepat karena Alpenglow adalah kode baru, dan Multiple Concurrent Leaders juga kode baru. Ada hal-hal yang bahkan tidak kita ketahui bahwa kita tidak mengetahuinya. Misalnya, karena alasan apa pun, Alpenglow akhirnya terlambat dari jadwal seperti Firedancer. Lalu bagaimana? Apakah kita terus menggunakan chain buruk dan lambat yang kita miliki sekarang? Tidak, kita harus berfokus untuk melaju cepat hari ini.

Saran tentang Rekayasa Performa

Sumber apa yang Anda rekomendasikan bagi seseorang yang berpengalaman dengan Rust dan ingin mempelajari coding performa serta profiling?

Pertama-tama, saya menyarankan penggunaan profiler yang bagus, yang saat ini belum ada, haha. Namun, semoga saya segera merilis profiler saya. Lalu, menurut saya cara terbaik untuk mempelajari sesuatu adalah dengan melakukannya pada hal yang benar-benar Anda pedulikan.

Jadi, saran saya bagi orang-orang yang ingin mempelajari pekerjaan performa adalah mencari software yang Anda gunakan setiap hari dan sukai, melakukan profiling, lalu membuatnya lebih cepat karena banyak software yang sangat lambat. Banyak software cepat pun dapat menjadi jauh lebih cepat. Komputer itu sangat cepat. Dan karena komputer sangat cepat, sangat mudah melakukan sesuatu secara lambat tanpa menyadarinya.

Menurut pengamatan saya, banyak orang menjadi ketagihan setelah menemukan sesuatu yang mereka gunakan lalu melakukan profiling—membuatnya lebih cepat, mengirim pull request, dan saya jamin pull request itu akan diterima. Anda akan sangat ketagihan.

Kernel hanyalah dependency lainnya. Saat mengerjakan sesuatu dan menggunakan library, kemungkinan besar pada suatu titik Anda perlu memeriksa library tersebut jika ada sesuatu yang tidak berfungsi, lambat, atau apa pun. Kernel hanyalah library lain. Jadi,, bacalah kode kernel. Kode kernel adalah salah satu kode paling sederhana yang pernah saya lihat. Jika Anda melihat scheduler di kernel, secara konseptual itu lebih sederhana daripada scheduler yang kami miliki di Solana. 

Namun, baca saja kode Linux. Kodenya menggunakan C, itu tidak ideal, dan apa pun yang bersentuhan dengan perangkat keras biasanya terkutuk, haha, tetapi sebagian besar Solana tidak bekerja langsung dengan perangkat keras. Jika Anda menemukan hal umum yang digunakan setiap hari, seperti syscall, Tokio, atau kode file system, itu sangat mudah. Baca saja. Dan jika Anda menghabiskan seminggu untuk membacanya, Anda akan memahaminya seperti kode lainnya. Anda akan merasa seperti seorang genius sialan. Anda akan berpikir, ahh, sekarang saya bisa mengerjakan kernel, paham?

Apa cara terbaik untuk mulai berkontribusi saat ini?

Saya lebih menyarankan untuk masuk ke Discord dan bergabung ke channel pengembangan di Solana Tech Discord. Misalnya, ada seseorang yang mengerjakan beberapa hal terkait jaringan. Beberapa hari lalu, dia memulai percakapan tentang kode TPU. Dan sejujurnya, dia lebih memahami cara kerja kode itu daripada kebanyakan orang di Anza. Anda bisa berkontribusi. Jika Anda sebaik orang itu dan mengirimkan patch kepada saya, saya akan menggabungkan patch tersebut.

Kami tidak banyak melakukan pengembangan internal yang tertutup. Jadi, jika Anda tidak melihat pull request pada bagian kode yang menurut Anda lambat, Anda pahami,, dan ingin Anda perbaiki, beri tahu saya di Discord. Kami akan membuat issue, menugaskannya kepada Anda, lalu Anda memperbaikinya.

Saya ingin orang-orang mengirimkan patch kepada saya. Saya memang ingin mengembangkan komunitas kami melalui pengiriman patch.

Pertanyaan Cepat

Apa bug tersulit yang berhasil Anda atasi tahun ini?

Miscompilation pada beberapa kode floating point yang menghambat rilis 2.2 beberapa bulan lalu. Itu bukan yang tersulit, tetapi paling membosankan karena saya harus menghabiskan berhari-hari hanya untuk membaca kode assembly.

Musik apa yang terus Anda putar saat menatap flame graph? 

Biasanya house atau techno minimal. Stephan Bodzin biasanya diputar berulang kali.

Apa distro Linux favorit Anda? 

Debian, tentu saja. Hanya itu yang tidak sangat menjengkelkan, haha.

Apa optimasi terbaik yang akan hadir bersama Alpenglow? 

Bahwa kami tidak akan mengeksekusi vote. Vote transaction itu [disensor]. Dan sangat bagus bahwa seluruh proses voting bukan lagi berupa transaction.

Apa pendapat Anda tentang ZK? 

Teknologinya hebat, tetapi menurut saya masih sangat berada dalam tahap riset untuk menskalakan blockchain. Jadi, saya tidak terlalu tertarik. 

Juli 2026, satu tahun dari sekarang, berapa prediksi Anda untuk waktu slot?

Secara pribadi, semoga lebih cepat dari itu, saya ingin memiliki slot 200 milidetik. Saya terus mengatakan kepada Toly bahwa dia harus membuat meme agar hal itu menjadi kenyataan. Jadi, semoga pada saat itu hal tersebut sudah terjadi. Saya rasa kita bahkan bisa melakukannya hari ini. Menurut saya, itu adalah batas minimum dalam arti bahwa hasil apa pun di atasnya merupakan kegagalan, tetapi kita bisa lebih rendah lagi.

Kapan Agave akan mencapai 1 juta TPS yang telah ditakdirkan itu? 

Haha, saya tidak akan memberikan jawaban singkat untuk pertanyaan itu. Saya terus bertanya kepada orang-orang, “Dari mana satu juta transaction itu akan datang?”

Kita akan mencapai satu juta TPS ketika orang-orang memiliki satu juta TPS untuk dikirimkan, tetapi sayangnya saya rasa itu tidak akan terjadi dalam waktu dekat. Saya memang pernah mengatakan bahwa jika Agave tidak mencapai satu juta TPS pada Oktober, saya akan berhenti dari pekerjaan saya. Jadi, mungkin saya harus mengarang demo, haha. 

Kesimpulan

Alessandro Decina mewakili jantung budaya performa Solana—upaya tanpa henti mengejar kecepatan yang berlandaskan rekayasa pragmatis, bukan kesempurnaan teoretis. Tim performanya memberikan hasil jauh melampaui ukuran mereka dengan menemukan dan memperbaiki “bug bodoh” yang secara kolektif menumpuk dan menyebabkan perlambatan sistemik.

Di dunia tempat banyak tim tersesat dalam visi arsitektur besar, tim performa Anza tetap berfokus penuh pada bottleneck yang tepat berada di hadapan mereka. Lakukan profiling, identifikasi, perbaiki, ulangi. Ini merupakan pekerjaan tidak glamor yang menghasilkan sesuatu yang memukau: blockchain yang benar-benar berkembang seiring perangkat keras, alih-alih mengakalinya.

Percakapan di atas mengungkap kebenaran mendasar tentang pembangunan sistem berperforma tinggi: kecepatan bukan hanya soal algoritma cerdas atau perangkat keras mutakhir. Kecepatan membutuhkan komitmen budaya untuk tidak pernah menerima “cukup baik” ketika “hebat” secara teknis dapat dicapai. Bagi Solana, itu berarti slot 200 milidetik, Async Execution, Multiple Concurrent Leaders, dan mempertahankan lebih dari satu juta TPS bukan sekadar pencapaian teknis—semuanya adalah keniscayaan.