Solana Preconfirmations — Radio Script (English)

Today's theme is speed. Not the speed of a blockchain, but something narrower and stranger. The speed at which you find out what already happened.

今日のテーマはスピードです。ブロックチェーンの速さ、ではありません。もっと狭くて、もっと奇妙なもの。すでに起きたことを、どれだけ早く知れるか、という速さです。

You would think so. But on Solana there's a gap between the moment a transaction's result exists and the moment anyone outside can see it. And that gap is where today's whole topic lives.

そう思いますよね。でも Solana には、トランザクションの結果が存在した瞬間と、外部の誰かがそれを見られる瞬間との間に、隙間があるんです。今日の話は、まるごとその隙間の中にあります。

In the illustrative example we'll use today, about thirty-five milliseconds. I want to flag that number honestly — it's a teaching figure, not a measurement. The published figure is a range, and we'll get to it.

今日使う説明用の例では、およそ 35 ミリ秒です。この数字については正直に断っておきたいのですが、これは説明のための数字であって、実測値ではありません。公表されているのは幅のある数字で、それは後ほど触れます。

To you and me, it is nothing. A blink takes about a hundred milliseconds. But a trading bot reacts in under one. So at that scale, thirty-five milliseconds isn't a rounding error — it's a long time, and long enough for someone else to reach the same opportunity first.

あなたと私にとっては、何もないのと同じです。まばたきは約 100 ミリ秒かかりますから。でも取引ボットの反応は 1 ミリ秒未満です。その尺度で見ると、35 ミリ秒は誤差ではありません。かなり長い時間で、他の誰かが同じ機会に先に手を伸ばすには十分な長さです。

A product called Preconfirmations. And before we go any further, I want to be very precise about one thing, because this is the part people get wrong. Preconfirmations is a product built by a company called Helius. It is not a standard feature baked into the Solana protocol.

Preconfirmations という製品です。そして話を進める前に、一つだけとても正確に言っておきたいことがあります。ここは誤解されやすい部分なので。Preconfirmations は、Helius という会社が作っている製品です。Solana のプロトコルに標準機能として組み込まれているものではありません。

Correct. Validators choose to forward their own stream to Helius, and Helius delivers that stream to subscribers over a WebSocket connection. If a validator doesn't opt in, there's nothing to receive. We'll come back to that, because it matters more than it sounds.

そのとおりです。バリデータが自分の意思で自分のストリームを Helius に転送し、Helius がそれを WebSocket 接続で購読者に届けます。バリデータが参加しなければ、受け取るものは何もありません。ここは後でまた戻ってきます。聞こえる以上に重要な点なので。

A signal that says, the leader executed this transaction, and here is the result. Success or failure, included.

「リーダーがこのトランザクションを実行しました、そして結果はこれです」と伝える信号です。成功か失敗かも含まれます。

This is the trap, and I'm glad you walked into it. The "pre" does not mean before execution. Execution has already finished. That's exactly why the signal can tell you whether the transaction succeeded or failed. The "pre" refers to the confirmation that is still ahead — the settlement steps that come later.

そこが罠なんです。踏んでくれて嬉しいです。この「pre」は、実行の前という意味ではありません。実行はもう終わっています。だからこそ、その信号は成功したか失敗したかを教えられるんです。「pre」がかかっているのは、この先にまだ控えている確定のほう。後から来る決済のステップのことです。

Not even slightly. It is a report. A very, very fast report.

少しも予測ではありません。報告です。とてもとても速い報告。

Because earlier, there is no result to report. Let me walk you through what happens inside a leader. A leader, by the way, is the validator whose turn it is to produce a block. Inside that leader, a transaction passes through six stages.

それより早いと、報告すべき結果がまだ存在しないからです。リーダーの内部で何が起きているか、順に見ていきましょう。ちなみにリーダーというのは、ブロックを作る順番が回ってきたバリデータのことです。そのリーダーの中で、トランザクションは六つの段階を通ります。

It arrives from the network. The leader verifies the signature. A scheduler sorts thousands of candidates by priority. Then execution. Then the results get recorded into entries. And finally those entries are split into fragments called shreds and pushed out to other validators.

まずネットワークから到着します。リーダーが署名を検証します。スケジューラが何千もの候補を優先度で並べ替えます。そして実行。次に結果がエントリに記録されます。最後にそのエントリが shred と呼ばれる断片に分割され、他のバリデータへ送り出されます。

Only at execution. That is the one moment a result is born. Before it, you have thousands of candidates that might make it. Stream that, and you're streaming noise.

実行のときだけです。結果が生まれる唯一の瞬間がそこです。それより前にあるのは、通るかもしれない何千もの候補だけ。それを流したら、流しているのはノイズです。

The result exists — but it's still locked inside the leader's machine. Everything after is packaging and shipping. Nothing has left the building yet.

結果は存在しています。でもまだリーダーのマシンの中に閉じ込められたままです。その後はすべて梱包と発送の作業です。まだ何も建物の外に出ていません。

Exactly. And here's the key insight. The emission point wasn't chosen for cleverness. It's the only place it could possibly be. It's the earliest moment a truthful report is even possible.

そのとおりです。そしてここが肝心な洞察です。この発信地点は、賢さを狙って選ばれたわけではありません。そこしかありえなかったんです。正直な報告が可能になる、いちばん早い瞬間だからです。

Helius publishes that preconfirmations run roughly five to fifty milliseconds ahead of shreds. Below that there's a whole ladder of observation points, all the way down to polling — where you just repeatedly ask a server, has it happened yet.

Helius は、preconfirmations が shred よりおよそ 5 ミリ秒から 50 ミリ秒早い、と公表しています。その下には観測地点の梯子がずっと続いていて、いちばん下はポーリングです。サーバーに向かって「もう起きましたか」と何度も聞き続けるやり方ですね。

You pay, but not in money. You pay in what you give up. At the top, you only get the status. Success or failure, and nothing else. Further down you get richer data and easier tooling — but the block has already propagated by then. Everyone knows.

支払いはします。ただしお金ではありません。差し出すもので支払うんです。いちばん上では、受け取れるのは status だけ。成功か失敗か、それ以外はありません。下に行くほど、より豊富なデータや扱いやすい道具立てが手に入ります。でもその頃にはブロックはもう伝播し終えています。みんなが知っているんです。

That's the whole ladder in one sentence. And the top rung does not replace the bottom rung. In practice, teams act on the fastest signal and verify with a slower one.

梯子の全体を一文で言うとそうなります。そして上の段は下の段の代わりにはなりません。実務では、いちばん速い信号で動き、遅い信号で確認する、という組み合わせになります。

Because a preconfirmation promises exactly one sentence. The leader executed this transaction with this result. That's it. It does not promise that the block will land. It does not promise the transaction stays on the canonical chain. And there is no economic penalty if it turns out wrong.

preconfirmation が約束しているのは、たった一文だからです。「リーダーがこのトランザクションを、この結果で実行した」。それだけ。ブロックが着地することは約束していません。そのトランザクションが正規のチェーンに残り続けることも約束していません。そして、もし違っていたとしても、経済的な罰則はありません。

Occasionally, yes. A block can be dropped when the network forks. And when that happens, the whole block goes, including transactions that executed perfectly.

たまに、あります。ネットワークが分岐したとき、ブロックが落ちることがあるんです。そしてそれが起きると、ブロックまるごと消えます。完璧に実行されたトランザクションも一緒に。

Yes. And this is the single most important distinction in the whole topic, so let me separate two things that sound identical. There are two completely different kinds of failure.

あります。そしてこれはこのテーマ全体で、いちばん重要な区別です。同じに聞こえる二つのものを、切り分けさせてください。まったく異なる二種類の「失敗」があります。

Kind one. Execution failure. The transaction ran, but it reverted. Not enough funds, a program error, a price moved too far. That's known at execution time, it's carried in the status, and you can filter it out.

一つ目。実行の失敗。トランザクションは動いたけれど、差し戻された。残高不足、プログラムのエラー、価格が動きすぎた、など。これは実行の時点で判明していて、status に載っていて、フィルタで除外できます。

The block doesn't land. This has nothing to do with whether your transaction was good — the entire block disappears. And at preconfirmation time, that is unknowable by anyone. The block hasn't been packaged, shipped, or voted on yet.

ブロックが着地しない。これはあなたのトランザクションが良かったかどうかとは何の関係もありません。ブロックまるごと消えるんです。そして preconfirmation の時点では、これは誰にも分かりません。ブロックはまだ梱包も発送も投票もされていないので。

Precisely. If you set the failed option to false, failed transactions are never streamed to you and never billed. But that filter says nothing about landing. For landing, you check afterwards, through the settlement levels — processed, then confirmed, then finalized.

そのとおりです。failed というオプションを false にすれば、失敗したトランザクションは配信もされず、課金もされません。でもそのフィルタは、着地については何も言っていません。着地のほうは、後から確定のレベルで確認します。processed、それから confirmed、そして finalized、という段階ですね。

And that's why we drew it as a two by two grid on the site. Because succeeded-and-landed, and succeeded-and-erased, feel the same to a beginner and are completely different to a system.

だからサイトでは、それを 2 かける 2 の表として描いたんです。「成功して着地した」と「成功したのに消えた」は、初心者には同じに感じられて、システムにとってはまったく別物なので。

Good. Ask it. And the answer is no, for a structural reason. Front-running means getting ahead of a transaction before it executes. But the preconfirmation is emitted after execution finishes. By the time you receive it, the result is already fixed. There is no room left to cut in line.

いい質問です。聞いてください。答えは「違います」で、それは構造的な理由によります。フロントランニングというのは、トランザクションが実行される前に、その前に割り込むことです。でも preconfirmation が発信されるのは、実行が終わった後です。あなたが受け取った時点で、結果はもう確定しています。割り込む余地は残っていません。

You act behind it, not in front of it. You learned a price is about to move, so you place the next order. You saw the oracle update, so you fire the liquidation. You saw the flow coming, so you pull your stale quote. That's reacting, not cutting in.

そのトランザクションの前ではなく、後ろで動くんです。価格がこれから動くと分かったから、次の注文を出す。オラクルの更新を見たから、清算を実行する。フローが来るのを見たから、古い気配値を引っ込める。これは反応であって、割り込みではありません。

Then it would be the opposite, and genuinely dangerous. That's the line between selling early visibility and leaking order flow.

そのときは話が逆になり、本当に危険です。早く見せることと、注文の流れを漏らすことの境界線が、まさにそこにあります。

Almost the opposite thing, despite the shared name. On Ethereum, a preconfirmation is a promise made before execution. A proposer commits that your transaction will be included, and that promise is backed economically — if they break it, they can be penalized.

名前を共有しているのに、ほとんど逆のものです。Ethereum では、preconfirmation は実行の前になされる約束です。提案者が、あなたのトランザクションを必ず含めると確約し、その約束は経済的に裏打ちされています。破れば罰を受けうる、という形で。

Yes. And it covers your single transaction. Nobody else's. Solana's version is the reverse on every axis. It arrives after execution. It covers everyone's transactions, not just yours. It's optimized for latency instead of certainty. And it needs no economic backing at all.

そうです。そして対象はあなたの一件だけ。他の誰のものでもありません。Solana 版はあらゆる軸で逆です。実行の後に届きます。あなたのだけでなく、全員のトランザクションを対象にします。確実さではなく、低遅延に最適化されています。そして経済的な裏打ちをまったく必要としません。

Because there's nothing to back. It isn't a promise. It's an observation. You can't break your word about something you already did.

裏打ちすべきものが無いからです。それは約束ではなく、観測だからです。すでにやったことについて、約束を破ることはできません。

Neither, and I want to be firm about that. Ethereum fills the gap of "I don't know if my transaction gets in." Solana fills the gap of "I find out later than everyone else." Different holes, different tools.

どちらでもありません。ここははっきりさせておきたいところです。Ethereum が埋めているのは「自分のトランザクションが入るか分からない」という穴。Solana が埋めているのは「他の人より知るのが遅い」という穴です。穴が違えば、道具も違います。

Connecting is the easy part. One WebSocket connection, one subscription request. The hard part is deciding what not to receive.

つなぐこと自体は簡単な部分です。WebSocket 接続が一つ、購読のリクエストが一つ。難しいのは、何を受け取らないかを決めることです。

Because the filters run on the server side. Transactions you filter out never reach you and are never billed. So how you design your filter is literally how you design your cost. You can filter by account, by region, by status.

フィルタがサーバー側で動くからです。除外したトランザクションは、あなたのところに届かず、課金もされません。だからフィルタの設計は、文字どおりコストの設計になります。アカウント単位、リージョン単位、そして status で絞り込めます。

Deliberately austere. A fixed header of eighteen bytes, then the raw transaction. The header holds four things: a version, the slot number, the position within that slot, and the status. It's bare because a fixed-length header decodes in nanoseconds, with no text parsing at all. If you're chasing thirty-five milliseconds, you don't want to spend it unpacking data.

あえて素っ気ない形です。18 バイトの固定ヘッダ、その後にトランザクションの本体。ヘッダには四つのものが入っています。バージョン、スロット番号、そのスロット内での位置、そして status です。素っ気ないのは、固定長のヘッダならナノ秒で解読できて、テキストの解析がまったく要らないからです。35 ミリ秒を追いかけているなら、それをデータの展開に使いたくはないですよね。

Ten credits per message, one message per streamed transaction, on the Professional plan or above.

1 メッセージあたり 10 クレジット、配信されるトランザクション 1 件につき 1 メッセージ。Professional プラン以上で使えます。

It's not a bug, it's a structural fact. You only get preconfirmations for slots led by a validator who forwards. And because a Solana leader holds four consecutive slots, the gaps arrive in groups of four.

それは不具合ではなく、構造上の事実です。preconfirmations が得られるのは、転送に参加しているバリデータがリーダーを務めるスロットだけです。そして Solana のリーダーは 4 スロット連続で担当するので、隙間は 4 つ単位でやってきます。

Exactly. And you can't switch it on from your side. It's decided by the validator. The upside is that forwarding earns them revenue, so as more stake participates, coverage widens.

そのとおりです。そして自分の側でオンに切り替えることはできません。決めるのはバリデータです。良い面としては、転送するとバリデータの収益になるので、参加するステークが増えるほどカバー範囲は広がっていきます。

Always. Act on the fastest signal, fall back when it's absent, and confirm settlement downstream. That's the honest architecture.

常に必要です。いちばん速い信号で動き、それが無いときは別の手段に落とし、確定は下流で確認する。それが誠実な構成です。

A preconfirmation moves your reaction point. Instead of acting after the network finds out, you act at the moment the leader executes. It tells you one true sentence, very early. It promises nothing about landing. And it covers everyone's transactions, not just yours.

preconfirmation は、あなたの反応地点を動かします。ネットワークが知った後に動くのではなく、リーダーが実行したその瞬間に動く。真実である一文を、とても早く教えてくれます。着地については何も約束しません。そして、あなたのだけでなく、全員のトランザクションを対象にします。

That gap is the entire point of the product. Everything else we talked about is just being honest about what it does and doesn't cover.

その隙間こそが、この製品の存在意義そのものです。他に話したことはすべて、それが何をカバーして、何をカバーしないかを、正直に述べただけです。

That's the show. Thanks for listening.

以上でおしまいです。お聴きいただき、ありがとうございました。