6月11日にアルゴランドのチーフ・プロダクト・オフィサーであるポールリーグルがツイートした内容は開発者の方に参考になります。
lots of discussions lately on building on L1s directly or building on current L2s/rollups/sidechains/subnets/parachains/fancynames. some thoughts
最近、L1（レイヤー１）上に直接構築するか、現在のL2/ロールアップ/サイドチェーン/サブネット/パラチェーン/ファンシーネームたち上に構築するかについて、多くの議論がなされています。
Why consider using L2s/rollups/sidechains/subnets/parachains/fancynames? because you believe you have a problem with your L1 that needs a solution.
なぜL2/ロールアップ/サイドチェーン/サブネット/パラチェーン/ファンシーネームたちの利用を検討するのでしょうか？なぜなら、あなたは自分のL1に解決すべき問題があると信じているからです。
For the most part, the L1 problem that these solutions solve is a real (or perceived) problem of scale/perf/cost. and, these solutions have done a reasonably good job alleviating these problems.
ほとんどの場合、これらのソリューションが解決するL1の問題は、スケーラビリティ/性能/コストという現実の（あるいは認識されている）問題です。そして、これらのソリューションは、これらの問題を軽減するために合理的に良い仕事をしてきました。
But, any solution to a problem brings new problems. The question is always, would you rather have your old problems or your new problems?
しかしながら、問題に対するどんな解決策も新しい問題をもたらします。問題は常に、古い問題と新しい問題のどちらを持つかです。
What are the new problems these particular solutions bring? They fragment ecosystems (and sometimes security), they introduce technical and security complexity which makes reasoning hard, they can break previous invariants, and they can make user experience confusing.
これらの特定のソリューションがもたらす新しい問題とは何でしょうか？それらはエコシステム（そして時にはセキュリティ）を断片化し、推論を難しくする技術的・セキュリティ的複雑さをもたらし、以前の不変性を壊す可能性があり、ユーザー体験を混乱させる可能性があるのです。
Unfortunately, we’ve now seen this play out in the broader blockchain ecosystem in the past few days. Existing contracts designed for an L1 without consideration for an L2, were used on an L2 and a nuance of the added complexity was missed resulting in a loss of funds.
残念ながら、私たちはこの数日間で、より広いブロックチェーン・エコシステムでこのような事態を目の当たりにしました。L2を考慮せずにL1用に設計された既存のコントラクトがL2上で使用され、追加された複雑さのニュアンスを見逃し、結果として資金が失われたのです。
To be clear, I believe this is a risk of the model, not of the various implementations or teams etc - I’ve been in similar situations in my career and my heart goes out to them.
明確にしておきますが、これはモデルのリスクであって、様々な実装やチームなどのリスクではないと思います。私は自分のキャリアで同様の状況に陥ったことがあるので、彼らには同情します。
What is the alternative? There’s no reason to bring in the problems above if you have a performant L1. It provides a single ecosystem, single security model, single user experience, etc.
@algorand is an example.
では代替案は何でしょうか？しっかりしたL1があれば、上記のような問題を持ち込む理由はありません。単一のエコシステム、単一のセキュリティモデル、単一のユーザーエクスペリエンスなどを提供するもの、例えばAlgorand（アルゴランド）です。
Algorand handles ~1100 TPS today, 6k in about a month, 10k soon after. 100% uptime with no degradation or stalling since genesis 3 years ago. Avg costs for all txs ~.001 Algos (currently $.0004). Final in 4.4s today, under 4s in about a month and ~2.5s soon after.
アルゴランドは現在、最大1,100TPS（毎秒トランザクション数）を処理し、その数は約1ヶ月後に6,000、その後すぐに10,000になります。3年前のGenesis以来、劣化も停止もなく稼働率100%です。全Txの平均コストは、.001 Algos (現在価値では$.0004)です。ファイナリティ（決済最終確定）は現在4.4秒、約1ヶ月後に4秒以下、その後すぐに2.5秒になります。
Algorand is actually final in 4.4s. not maybe final, pretty final, mostly final, kind of final, final here but not there, etc.
他のように「おそらく最終」、「かなり最終」、「ほとんど最終」、「一種の最終」、「ここでは最終だがそこでは最終ない」などではなく、アルゴランドでは実際に「4.4秒で最終」です。
Algorand’s growing and thriving ecosystem is nodding their heads right now, but others might say, “yes, sounds amazing, but this brings a new problem too. my users are [there] and not currently on Algorand”
アルゴランドの成長し繁栄しているエコシステムは、今これを聞いてうなずいていると思いますが、他のエコシステムの人は「はい、素晴らしいようですが、これも新しい問題をもたらします。私たちのユーザーは他のチェーンにいて今アルゴランドにいないのです」と言うかもしれません。
To which I say your users are there for your value prop, not the underlying blockchain. They care about the chain your solution is built on for only one reason: the user experience it creates.
それに対して私は、「あなたのユーザーはあなたの価値提案のためにいるのであって、基礎となるブロックチェーンのためにいるのではないでしょう」と言います。彼らがあなたのソリューションが構築されたチェーンを気にする理由はただ一つ、それが生み出すユーザー体験です。
How long does it take to bridge your asset? Finality of the chain. How quickly will fees escalate? Capacity of the chain. How much downtime will your dapp have? Historical uptime of the chain. How responsive is the dapp? latency of the chain. and on and on
あなたの資産をブリッジするのにかかる時間は？ チェーンの最終性の問題です。料金が上昇する速さは？ チェーンの容量の問題です。あなたのアプリケーションがダウンする時間は？ チェーンの過去の稼働時間の問題です。アプリケーションの応答性は？ チェーンのレイテンシーですね。などなどたくさんあります。
Do the work to understand how what you’re building *on* impacts the experience of you’re building; Your users should be laser focused on your value prop, not your technology stack.
あなたがアプリケーションを構築している基盤が、そのアプリケーションのユーザー体験にどのように影響するかを理解する必要があります。あなたのユーザーは、あなたの技術スタックではなく、あなたの提案する価値にフォーカスすべきです。
Finally, am I saying that current L2s/rollups/sidechains/subnets/parachains/fancynames are bad? definitely not - when you have problems you need solutions. but, you must ask yourself, do you like the new problems they bring more than the current problems you have?
最後に、私は現在のL2/ロールアップ/サイドチェーン/サブネット/パラチェーン/ファンシーネームたちが悪いと言っているのでしょうか。もちろん違います。問題があるときには解決策が必要です。でもあなたが自分自身に問うべきは、今抱えている問題よりも、その問題がもたらす新たな問題の方が好きなのかどうかということです。