エンジニアリングの速度：Alessandro Decinaと探るAnzaパフォーマンスチームの内側
はじめに
テクノ・オプティミズムは、間違いなくSolanaの文化的な時代精神です。際限のない速度、進歩、イノベーションへの揺るぎない信念が、mainnetへ送り出されるすべてのpull requestの根底にあります。合言葉はIBRL、すなわち帯域幅を増やし、レイテンシを減らすです。それはエンジニアリング上の至上命令であり、文化的な合言葉であり、世俗的な祈りでもあります。Bitcoinが永続性をたたえる大聖堂で、Ethereumが中立性を追求するアゴラなら、Solanaはレーストラックです。測定可能な機械的速度が支配する領域です。
しかし、この速度が、丁寧にコメントされたdiffとして天から降ってくることはありません。一日中コードを見つめる覚悟を持つ人々が掘り出し、磨き上げ、現実のものにしています。Alessandro Decinaほど徹底して見つめる人はほとんどいません。もともとGStreamerの達人で、動画バッファのカクつきを個人的な侮辱と受け取るような人物です。現在はAnzaの4人編成のパフォーマンスチームを率いています。このチームにとっての「セルフケア」とは、午前3時にvalidatorのtraceから黄色いバーを消すことです。日々の仕事はflame graphを見つめ、workflow全体を取り除き、実戦で鍛えられたproduction codeを書き直すことです。最適化できるものは、いずれ必ず最適化されるからです。
この速度の中で生きるとはどういうことなのかを知りたいと思いました。そこでAlessandro Decina本人に話を聞き、現存する最速のブロックチェーンをどのようにしてさらに高速化し続けているのかを探りました。以下のインタビューは、速度の解剖記録です。マルチメディアパイプラインに携わっていた時代から、4人のエンジニアが組織全体を上回る成果を出せるようにする文化的なガードレールまで、幅広く話を聞きました。
この対談は、明瞭さと簡潔さを重視して編集・要約しています。
インタビュー
原点と世界観
Ichigo：少し昔を振り返ると、最初に夢中になったのはGStreamerとマルチメディアパイプラインでした。当時、レイテンシについて得た最大の教訓は何でしたか？リアルタイムの音声と映像を追求した経験は、Agaveから数ミリ秒を削るうえで何を教えてくれましたか？
Decina：まず、僕のことをよく調べましたね、はは。GStreamerには15年くらい、もしかするともう少し長く携わっていました。実際、僕が知っていることは文字どおりすべてそこで学びました。プロジェクトがオープンソースとして始まったばかりの頃に貢献を始めました。本当に運が良くて、当時の創設者と親しくなれたんです。彼は僕より、そうですね、15歳くらい年上で、本当に優秀でした。Wikipediaに載っているくらいだから、たぶん頭が良いんでしょう。僕とは違います。僕は頭が良いふりをしているだけです。彼は何の見返りも求めず、自分の知識をすべて僕に教えると決めてくれました。それで、そこで仕事を始めました。
今Solanaに携わりながら低レイテンシについて話しているのは面白いですね。これはまったく低レイテンシではないからです。音声処理、DPS、マルチメディアハードウェアの世界から見れば、Solanaで行っていることは非常に高レイテンシです。音声や映像の応答時間が400ミリ秒もあれば、実質的に壊れています。使い物になりません。
その後、Linuxドライバーや、映像と音声のエンコードおよびデコードを行うハードウェアに携わるようになりました。今やっていることの多くは、当時やっていたことと本質的に同じです。ハードウェアを扱う際のレイテンシは、どこかにqueueがあることを意味します。そのqueueを見つけ、可能な限り小さくして、underflowが決して起きないようにします。
たとえば、今取り組んでいるXDPは、音声のring bufferの動作とよく似ています。今こうして通話している間にも、多数のpacketが順不同で届いています。どこかにすべてのpacketを並べ替えるring bufferがあり、絶対にunderflowしないようにする必要があります。
この20年間、ずっと同じ仕事をしてきたような気がします。
いわば、日が変わってもやることは同じ、というわけですね。Spotifyでも働いていましたし、Firefoxにも少し関わっていたようですが——
ああ、違います。Firefoxの件は、hackathon向けのintegration作業をしただけです。はは、僕はかなり年寄りなので、GStreamerを使ったFirefox初のvideo tagを書いたんですよ。
すごいですね、はは。つまり、すべての道はGStreamerに通じているのですか？
GStreamerからは、マルチスレッドプログラミングを本当に学びました。僕がこのecosystemにいる理由でもあります。Assemblyを書いたり、さまざまな低レベルのhackをしたりする人がいます。僕からすれば、そういうことはもう長い間やってきました。そして、強力な型システムと優れたcompilerを備えた言語がなければ、結局は自分で自分の足を撃つことになると学びました。Assemblyならわずかに速いものを作れるかもしれませんが、僕はどうしてもRustを使いたいのです。
Rust compilerには、こう言ってほしいのです。お前は馬鹿だ。ここにbugがあるから、これは動かない。Rust以前の僕は、10%がsoftware engineerで、90%が生身のdebuggerだったように感じます。ただひたすらdebugしていました。ですから、GStreamerとRustへの愛が、Solanaに携わり始めた理由だと思います。Rustの人気が高まりつつありましたが、フルタイムで使える仕事はあまりありませんでした。そして僕は、Rustだけを使って仕事をすると決めていました。
Cを書くには歳を取りすぎました。memory safetyのない言語は使いたくありません。時間を無駄にしたくないんです。そういうわけで、今ここにいます。
いいですね。では、転向した当時、validator codeに携わる前の分散型システムについて何か誤解はありましたか？Solanaのarchitectureが実際にscaleできると確信した理由は何ですか？
実はSolanaへの参加が2年近く遅れました。Rust compilerの仕事で忙しかったからです。Solanaでvirtual machineの開発を始めたばかりの人から、「同じことをしています。あなたのほうが少し先に進んでいるようなので、一緒に働きませんか」というメールが届きました。そのメールには返信しませんでした。Bitcoin、次にEthereumを調べて、処理を実行できることは分かりましたが、10 TPSしかなかったからです。本格的なプロジェクトとは言えませんよね？10 TPSでは現実世界で使えることは何もできません。
ですから、そのメールには返信しませんでした。単に、このcrypto界隈の人たちは、まだ本気ではないなと思ったんです。
2年後にTolyから連絡が来て、SOLの価格を確認しました。あのメールを開いておけばよかった、と思いましたね、はは。今回は彼と話すことにしました。話す前に、彼からいくつかのcodeを紹介されました。見てみると、正直言ってひどいものでした。本当に質の悪いRust codeでした。
でも、Tolyが誰なのかをGoogleで調べずに話したので、彼については何も知りませんでした。彼は頭が良く、的確なことばかり言いました。私たちはこれを構築している、現状はこうだ、明らかに最先端ではないが、hardwareに合わせてscaleすることを目指している、と。最も高性能なブロックチェーンを構築し、最終的にはhardwareがbottleneckになるようにする。hardwareを増やすほどscaleするものを作る、という考えでした。
それには納得できました。単に第三次世界大戦をネタに興奮しているブロックチェーン狂の集まりではないと感じたんです……僕が興味を持っているのは技術です。僕は本当に技術目的でcryptoに関わっている数少ない人間の一人です。
Solanaには、テクノ・オプティミズムの影響を強く受けたエンジニアリング文化があります。つまり、帯域幅を増やし、レイテンシを減らすという文化全体です。個人的にはどう捉えていますか？また、それはAnzaの日々の仕事にどのような影響を与えていますか？
僕から見ると、Ethereumは根本的にscarcity mindsetを持っています。いくつかの壁に突き当たったから、その壁を回避する方法を探そうとしているように見えます。本質的には自分たちの知識の不足であり、どうしても解決できないと感じている問題のために、これだけのinfrastructureを発明しようとしているわけですよね？
一方、僕たちは正反対だと感じます。問題があるなら、物理法則に反するものを除き、解決不可能な問題はありません。これは非常に大きな文化的な違いです。
何かが壊れていたら、まず座って少しprofileし、問題が何かを確認します。traderやmarket makerと話し、彼らが抱える問題を確認します。最近、非常に具体的な問題をいくつか見つけました。そのほとんどは修正済みです。本当に、2〜3か月あればすべて修正できます。
現在のSolanaには、機能していないものが数多くあります。私たちはそれを把握していますが、腰を据えて「完璧な解決策ができた！さらに進むには、新しい何かを発明するか、別の研究や作業が必要だ」と考えたことはありません。違います。どれも具体的な問題です。そのほとんどは、本当にくだらない問題です。
それに、最近はoutageがありません。個人的には、それは弱気材料だと思います。少し保守的になり始めた人がいると思うからです。もっとずっと速くできると分かっています。明日にでも100 million CU blockを実現できると分かっています。必要なのは、いくつかのことを一気に片付けることだけです。僕は、すべてを一気に進めるべきだと思っています。
根本的に分かっていることがあります。現在のperformanceを10倍にできると知るためにroadmapは必要ありません。その方法が見えています。やり方も分かっています。すでにcodeを書いていて、まだ完全ではないものもあれば、codeは完成していても、修正すべきedge caseが残っているためdeployできないものもあります。しかし、何をすべきかは正確に分かっています。
これをscaleさせる方法は分かっています。
パフォーマンスエンジニアリング
パフォーマンスの取り組みについてですが、Anzaに専任のパフォーマンスチームがあることは、あまり知られていないと思います。少し目立たない存在ですよね。チームの構成について教えてください。Anzaの他のエンジニアリングチームとは何が違いますか？
そうですね。Anzaには複数のチームがあります。現在Alpenglowに注力しているconsensus担当、主にGossipに注力しているnetworking担当がいます。基本的にaccounts databaseだけを扱うAccountsDB担当もいます。schedulerに取り組むblock productionチームもあります。もちろん、今思い出せていない他のチームもあります。
パフォーマンスチームとの違いは、あらゆるものを扱う点です。profileしてbottleneckを見つけ、関連チームに時間と専門知識があるかを確認します。誰でも修正できるわけではない問題が見つかることもあるからです。たとえばconsensus担当者は、専門分野が異なるため、必ずしも低レベルプログラミングが得意とは限りません。その場合は通常、私たちが入り込んで代わりにcodeを修正します。
ですから、1つのことだけに取り組むわけではありません。次のbottleneckを見つけます。およそ2週間ごとに状況を共有し、現在地、次にすべきこと、次のreleaseをどう高速化するかを決めます。
もう1つの大きな違いは、Anzaが優秀な人を採用する傾向にあることです。Rustを知らなくても問題ありません。低レベルプログラミングを知らなくても問題ありません。頭が良ければ、こうしたskillの大半は仕事をしながら教えられると考えています。一方、パフォーマンスチームでは、現在直面しているbottleneckの性質上、kernelやその他の低レベル領域の経験を持つ人を採用することが多いです。
たとえばaccounts databaseには、修正すべきalgorithm上の問題がいくつかあります。ですが*,*、2.3 releaseのaccounts databaseが2か月前の約10倍高速になった理由は、単にI/Oの方法を修正したからです。高速化するには、その仕組みを理解する必要があります。databaseを高いレベルでしか理解していなければ、diskの動作は十分に分かりませんし、kernelがI/O requestをどうscheduleするかを知る必要もありません。
ですから、個人的にパフォーマンスチームでは、より低レベルに強い人を採用する傾向があります。繰り返しますが、Rustを知っているかどうかは気にしません。ただし、CやC++を使って、より低レベルな領域に携わった経験は求めます。
パフォーマンスチームの存在があまり知られていない理由は、実質的に12月に始まったばかりだからです。僕はもともとcompilerに取り組むために採用されましたが、2024年3月のoutage前後にperfへ移り、最適化を始めました。ある日突然、自分がやりたいことに取り組むと周囲に告げたので、みんなあまり快く思っていませんでした。そうですね、はは、不満だったんです。でも、その後とても良い成果が出ました。すると人々が僕のところに来て、「分かりました。実際、この仕事をする人をもっと採用したいですか？」と聞くようになりました。そして12月にperfの取り組みを正式化し、チームを立ち上げました。
正直、ひいき目はありますが、パフォーマンスチームは文句なしにAnzaで最高のチームです。間違いありません。
疑っていませんよ、はは。チームは何人ですか？
フルタイムでは4人ですが、Brooksや他の数人が加わったとTwitterで冗談を言っています。僕のprofilerを、より幅広い人に共有し始めたからです。2か月ほど前までは、profilerにaccessできるのはパフォーマンス担当だけでした。今は全員が使えます。たとえばBrooksは、profilerを渡してから、僕よりも多くのパフォーマンス作業をしています、はは。完全にはまっています。今では、あらゆるものを高速化しています。
ですから今は、非公式にはBrooksや他の数人も多くのパフォーマンス作業をしています。ただし、フルタイムでパフォーマンスに取り組んでいるのは4人です。
では、パフォーマンスに取り組む際、profile中に探す、多くのエンジニアが見落とす「異臭」のような兆候は何ですか？何を最適化すべきか、どう判断しますか？
本当に分かりやすいものもあります。初めてAgaveをprofileしたとき、user space codeを実行するよりもkernel内でずっと多くの時間を費やしていました。これは異常です。私たちは低レベルな種類のapplicationではありません。マルチメディアframeworkであれば、最終的にsampleをhardwareへ送る必要があるため、作業の大半をkernelで行うのは理にかなっています。しかし、私たちが行う本当に低レベルな作業はTurbineだけです。
ですからprofileを始めたとき、最大の兆候はflame graphに大量の黄色が見えることです。kernelで時間を使いすぎているという意味だからです。おそらく誰かが、一見無害に見える高レベルAPIを使っていて、その内部ではperformanceの面でひどい処理をしているということです。
この1年で、Agaveが使用するmemory量を約10分の1に減らしました。全般的に同じ問題にぶつかるからです。memory allocationを行いすぎると、いずれkernelとのやり取りが必要になります。profilerではkernelとのinteractionが見えます。これはどこから来ているのかを確認すると、このchainが常にmemoryを激しく消費していると分かります。大量のmemoryを使い捨ててallocationしている場所まで遡り、そこを修正します。
より難しいものもあります。たとえば、私たちが発見し、僕が修正している根本的なdesign上の問題があります。よく知られているように、Solanaはpipeline化され、複数のstageがあります。すべてが並列化され、処理が並行して走るはずです。
実際には、architecture上、pipeline designは存在しますが、このpipelineには非常に多くのstallがあります。複数のstageはあるものの、さまざまな箇所にレイテンシを生む愚かなdesign bugのせいで、すべてのstageのthroughputを最大化できていません。このレイテンシこそ、transactionを送れないときや、systemにjitterがあると言うときに、人々が通常不満を訴える原因です。このjitterは、根本的な要因やhardwareによって生じているのではありません。単に私たちが最適ではない方法で処理しているだけです。
ただ、完全に率直に言えば、私たちが取り組んでいるのはくだらない問題です。極めて明白なbugがいくつかあり、その明白なbugを修正しているだけです。
こうしたbugについて、micro-benchmarkを使うべきか、mainnet trafficを完全にreplayすべきか、どのように判断しますか？
私たちが抱えるパフォーマンス問題の大半は、人々がmicro-benchmarkを書いたことに由来すると思います。micro-benchmarkを高速化し、単独でtestしました。しかし、Agaveですべてを組み合わせると、何一つmicro-benchmarkどおりには動きません。
ですから、僕は個人的にこう言っています。何に対してもmicro-benchmarkを使わないでください。transactionのreplayですら、この1年で行ったのは3回ほどです。mainnet trafficをreplayしても、実際にmainnet trafficを実行するときとまったく同じ速度ではreplayできず、多くの条件が変わるからです。
startupを大幅に高速化している理由の一部もこれです。そうしなければ、修正が機能するか確認するたびに30分待つ必要があり、面倒だからです。
今のAgaveの段階まで来ると、1つのcomponentだけを追って深いrabbit holeに入り込むことはできません。知的には興味深い仕事かもしれませんが、system全体を考慮しなければまったく役に立ちません。実際には何も前進させないからです。
system全体を見る場合、TurbineをXDPベースに書き直すことが、なぜそれほど重要なのでしょうか？
Solanaの直前にはnetworkingに取り組んでいました。deep packet inspectionを行うstartupにいました。基本的にはNICに入るすべてのtrafficをinterceptし、悪意のあるflowを止めるためにリアルタイムで分析してから、kernelへ再注入します。実質的に、Rust、Tokio、そしてもちろんXDPを使い、user spaceでTCPとUDPのstack全体を書いていました。
Anzaに入ったとき、いずれXDPを使う必要があることは明らかでした。Firedancerが始動したとき、彼らは「TurbineのXDP実装から始めます」と言いましたが、僕は愚かだと伝えました。理にかなっていません。XDPは客観的に見てひどいAPIなので、はるかに時間がかかります。そのため、車輪が文字どおり外れるまで、できる限り長く使わずに済ませたいものです。
そして、ああ[削除済み]、もうXDPを使うしかない、となります。私たちにもそれが起きました。pipelineにある他のすべてのbottleneckを取り除いてきましたが、load testを始めた日に、Turbineが完全に動かなくなるのを目にしました。
そこで、これは明らかにもう実用にならないと判断しました。実はXDPを使わずに済むよう、本当に必死に試しました。以前使った経験から、どれほどひどいか知っていたからです。io_uringベースのTurbine実装を作ろうとしました。するとio_uringでいくつかのbugを見つけ、そのbugを修正し始めました。まだ送りたいkernel patchがいくつかありますが、ある時点で、Solanaを実行するために僕のcustom kernelを使うよう、すべてのvalidator operatorへ要求することはできないと気づきました。
XDPを使うしかなくなり、実際に使いました。そして今は動いています。
答えは、次のbottleneckを見つけ、それを修正することです。そして、見つけたbottleneckをすべて修正し続けます。明日の問題は明日考えればよいのです。それが僕のモットーです。明日のことだけを心配することもできますが、そうすれば今日はひどい状態になります。現在のSolanaはひどい状態です。blockは小さすぎ、Turbineはレイテンシを増やしすぎ、schedulerにはまだ問題があります。今日、問題を修正しなければなりません。そうしなければ、それほど速く進める明日はありません。
パフォーマンスのregressionはどのように防いでいますか？Firedancerとはどのように連携していますか？
perf regressionへの対応は大変です。僕は個人的に、毎日、少なくとも1日に数回はAgaveの何かをprofileしています。それでもregressionは頻繁に起きます。高性能なcodeを書くこと自体が1つの仕事だからです。高性能なcodeの書き方を知る必要があります。Rust codeを書けば、平均的にはNode.js codeやPython codeなどを書くより高性能になります。しかし、たとえば数百万itemのcollectionを扱うAccountsDBに携わる場合、ただcodeを書けばよいわけではありません。algorithmを構築し、大規模なdatasetを効率良く扱うのは難しいことです。
そのため、ときどきregressionが起きます。1か月ほど前までは、僕はほとんど全員に怒鳴っていました、はは。AccountsDBのBrooksには、一時期嫌われていたと思います。今はとても良い関係ですが、1か月前までは、やり取りのほぼ半分が、AccountsDBの何かが遅くなったことで僕が彼に怒鳴るというものでした。
protocolについては、Firedancerとの連携によって改善しました。protocolの多くの部分は、さまざまな課題への対応として自然発生的に拡張されてきたと感じるからです。protocol開発は1つのideaから始まり、それをproductionに投入します。そして多くのideaと同じように、最初からうまくは動きません。そこで、その上に別のものを追加し始めます。上に追加されたものの多くは、performanceの観点から見ると非常に悪いideaでした。
たとえばGossipには、epoch slotsと呼ばれるものがありました。clusterが基本的に、誰のvalidatorがどのslotを確認したかを全員へbroadcastするものです。6か月前、別のものを何気なくprofileしていたとき、このepoch slotsがCPU時間の面で、実際のtransaction実行よりも多くの時間を使っていることに気づきました。bandwidthの面では、Turbineの4倍を消費していました。これは、問題を緩和するために、ある時点でprotocolの上に作られた場当たり的なpatchにすぎません。
今は、こうしたことはもう起きていません。その一因はFiredancerです。現在は誰かが提案を行うと、Firedancerと連携する必要があります。彼らは当然、別のclientを作っていますからね、はは。そのため、作業量を見積もる必要があります。この提案の実装にどのくらいかかるのか、優先度はどれくらいかを判断する必要があります。そのため、良くも悪くも異議を唱えます。私たちが行う変更の多く、あるいはほぼすべてに反対意見を出します。そして、本当に悪い変更へ異議を唱えることに非常に長けています。
TurbineのXDP版がreleaseされた後、meetingも対立もない1か月があり、好きなことに取り組める完全な自由が与えられたら、Agaveのどの部分を最初に最適化または再設計しますか？
本当にやりたいんです。文字どおり夢に見るほどです。AccountsDBを2年ほど前からずっと書き直したいと思っています。ただ、始めたら文字どおり人生の1〜2か月を費やすことになると分かっています。今のところ、それは僕にとって最善の時間の使い方ではありません。でも、いつかやります。Brooksにやらせようと何度も圧力をかけていますが、彼がやらなければ、いずれ僕がやります。
今後の展開
Async ExecutionやMultiple Concurrent Leadersといった計画中の機能を見据えた場合、パフォーマンスチームにとって最大の頭痛の種は何でしょうか？
直感的には、asyncが嫌いです。現在のmodelは非常に単純です。いくつかのtransactionを受け取り、非常に高速でreplayしてからvoteします。概念的にはとても簡単です。Asyncはdesignを難しくしますが、chainを実際に使う体験は大幅に向上させます。
Multiple Concurrent Leadersのdesignも嫌いです、はは。特に高速取引を行うなら、複数のleaderが必要なのは理解しています。他に選択肢はありません。ただ個人的には、少なくとも12か月は実現しないものだと思っています。ですから、あまり気を取られたくありません。
1年後にAlpenglowが存在することは重要ですが、来月に100 million CUsを実現することも重要です。今あるものの高速化に集中する必要があります。Alpenglowは新しいcodeで、Multiple Concurrent Leadersも新しいcodeだからです。未知の未知があります。何らかの理由で、AlpenglowがFiredancerのように予定より遅れたとしましょう。そうなったらどうしますか？今のような、ひどく遅いchainを使い続けるのでしょうか？違います。今日、高速化することに集中しなければなりません。
パフォーマンスエンジニアリングへの助言
Rustの経験があり、パフォーマンスを意識したcodingやprofilingを始めたい人に、どのようなresourceを勧めますか？
まず、優れたprofilerを使うことを勧めます。現時点では存在しませんが、はは。僕のものを近いうちにreleaseできればと思っています。そして実際、何かを学ぶ最善の方法は、自分が本当に関心を持つものに取り組むことだと思います。
ですから、パフォーマンス作業を学びたい人への助言は、毎日使っていて大好きなsoftwareを見つけ、それをprofileし、高速化することです。多くのsoftwareは非常に遅いからです。高速なsoftwareでさえ、もっとずっと速くできます。computerは本当に高速です。そして非常に高速だからこそ、遅い処理をしていても、気づかずに済んでしまいます。
多くの人が夢中になる流れは、普段使っているものを見つけてprofileし、高速化してpull requestを送ることです。必ず受け入れられると保証します。きっと夢中になります。
kernelも他のdependencyと何ら変わりません。何かに取り組んでlibraryを使っているとき、何かが動かない、遅いなどの問題があれば、いずれそのlibraryの中を見ることになるでしょう。kernelも単なる別のlibraryです。ですから、*,*kernel codeを読んでください。kernel codeは、僕がこれまで見た中でも特に単純なcodeです。kernelのschedulerを見ると、概念的にはSolanaのschedulerより単純です。
とにかくLinux codeを読んでください。Cなので理想的ではありませんし、hardwareに触れるものはたいてい呪われています、はは。ただ、Solanaの大部分はhardwareを直接扱いません。syscall、Tokio、file system codeなど、毎日使う汎用的なものを見つけてください。とても簡単です。読んでみてください。1週間かけて読めば、他のcodeと同じように理解できます。そして、自分がものすごい天才になったように感じるでしょう。「ああ、これでkernelの仕事もできる」と思えるようになります。
今すぐ貢献を始める最善の方法は何ですか？
僕としては、Discordに参加し、Solana Tech Discordのdevelopment channelに入るのが一番です。たとえばnetworking関連に取り組んでいる人がいて、先日TPU codeについて会話を始めました。正直、Anzaの大半の人よりも、そのcodeの仕組みをよく理解しています。誰でも貢献できます。彼ほど優秀で、僕にpatchを送ってくれれば、mergeします。
社内限定の非公開開発は、あまり行っていません。そのため、自分が詳しく、遅いと思うcodeにpull requestが見当たらず、*,*それを修正したいなら、Discordで僕に伝えてください。issueを作成して担当を割り当てるので、修正してください。
僕はみなさんにpatchを送ってほしいと思っています。patchを送ってもらうことで、communityを成長させたいです。
一問一答
今年解決した中で、最も難しかったbugは何ですか？
ほんの数か月前、2.2 releaseを妨げていた浮動小数点codeのmiscompilationです。最も難しいものではありませんでしたが、何日もassembly codeを読む必要があり、最も退屈な作業でした。
flame graphを見つめるとき、繰り返し聴いている音楽は何ですか？
たいていhouseかminimal technoです。Stephan Bodzinをよくloop再生しています。
お気に入りのLinux distroは何ですか？
間違いなくDebianです。ひどく煩わしくない唯一のものです、はは。
Alpenglowで実現する最良の最適化は何ですか？
voteを実行しなくなることです。Vote transactionは[削除済み]です。voteに関する処理全体がtransactionではなくなるのは、本当に素晴らしいことです。
ZKについてどう考えていますか？
素晴らしい技術ですが、ブロックチェーンのscaleという面では、まだかなり研究段階にあると感じています。そのため、それほど強い関心はありません。
今から1年後の2026年7月、slot timeはどのくらいになると予想しますか？
個人的には、それより早く実現してほしいですが、200ミリ秒のslotを実現したいです。Tolyには、それをmemeの力で現実にする必要があると繰り返し伝えています。ですから、その頃までには実現していると期待しています。今すぐでも可能だと思います。それが最低ラインです。それを超える時間がかかるなら失敗だという意味ですが、さらに短くすることもできます。
Agaveが運命の1 million TPSに到達するのはいつですか？
はは、それには一問一答では答えません。「100万件のtransactionはどこから来るのですか？」と、みんなに聞き続けています。
人々が1 million TPS分を送れるようになれば、私たちも1 million TPSを実現します。しかし残念ながら、すぐには起きないと思います。Agaveが10月までに1 million TPSを達成しなければ仕事を辞める、と言ってしまいました。ですから、でっち上げのdemoを用意する必要があるかもしれません、はは。
まとめ
Alessandro Decinaは、Solanaのパフォーマンス文化を動かす心臓そのものです。理論上の完璧さではなく、実用的なエンジニアリングに根差し、速度を絶えず追求しています。彼のパフォーマンスチームは、その規模からは想像できないほど大きな成果を上げています。積み重なってsystem全体のslowdownを引き起こす「くだらないbug」を見つけ、修正しています。
壮大なarchitectureの構想に迷い込むチームが多い中、Anzaのパフォーマンスチームは目の前にあるbottleneckだけに照準を合わせ続けています。profileし、特定し、修正し、繰り返します。華やかではない仕事ですが、hardwareを回避するのではなく、hardwareとともに実際にscaleするブロックチェーンという華々しい成果を生み出しています。
上の対談は、高性能systemを構築するうえでの根本的な真実を示しています。速度を決めるのは、巧妙なalgorithmや最先端のhardwareだけではありません。技術的に「卓越」を実現できるなら、決して「十分」で妥協しないという文化的な決意が必要です。Solanaにとって、200ミリ秒のslot、Async Execution、Multiple Concurrent Leaders、そして1 million TPSを超える持続的な処理は、単なる技術的milestoneではありません。必然なのです。
Heliusを購読
Solana開発の最新情報や新しい記事の公開通知を受け取れます