Neon AMA with Anatory (SolanaTV和訳)
話し手の紹介/概要
Neon EVMは、EthereumのようなトランザクションをSolana上で処理するためのツールです。Solanaにおいて重要な特徴：並列処理を可能とする強みを生かしてNeon EVMでも並列処理が行えるよう設計されているものになります。今回は、アナトリー主催のNeon AMAを見ていこうと思います。(基本自分のメモ的感覚です)
----------
・Anatory Yakovenko
(Solana CEO)
・Vitali Dervoed
(Product Marketing Manager)
・Semen Medvedev
(Software Enginner)
・Marina Guryeva
(CEO)
・James lkeguchi
(head of strategy and BizDev)
*正確なものを聞きたい場合は、ご自分でSolanaTVをご視聴ください。ところどころ力尽きています、、、
本編
Anatory：こんにちは、みなさん！それでは始めていきましょう。私、アナトリーはSolanaを開発したSolana labの共同設立者です。今回はEVM互換性を持つNeonについてお話してきます。
Marina：そうですね！自己紹介していきますね。私はNeon labsのMarinaです。ここにいるガイドメンバーもラボから一緒に来ていますよ。私たちはこのイーサリアムに互換性を持つ仮想マシンを構築しています。
Anatory：いいですね。では、まず実際にNeonが何かということから始めましょう。スマートコントラクトなのか、サイドチェーンなのか、どうやって違いを説明すればいいのか、他のEVMとはなにが違うのでしょうか？
Marina：おっけー。Neon EVMを理解するためのキーポイントは、Solana上のスマートコントラクトであるということです。これは並列処理が可能なSolanaならではの利点でもあります。
Anatory：すばらしい！質問2について聞いてしまったような気がしますが、、、（笑）さっそくみんなに自己紹介しましょう！
James：そうですね！皆さん、こんにちは。僕はNeon labの戦略・開発部門の責任者であるJames lkeguchiです。みなさん質問を読んで、あなたたちとお話するのがすごく楽しみです！
Vitali：こんにちは、アナトリー。私はNeon labの プロダクト・マーケティング・マネージャーのVitaliです。
Semen：こんにちは。みなさん、わたしはSemenです。どうぞよろしく。
Marina：そうだね、私たちがNeon labを運営していることを紹介できたから質問の続きを答えていこう！アナトリーよろしくね！
Anatory：うん、じゃあこれがスマートコントラクトであることが興味深いんです。ほとんどの場合EVMの実行については、IBCチェーンやポルカドットのようなパラチェーンで行われています。そう、だから実質的には、Solanaのスマートコントラクトでしかないのに、これほどまでに重要なんですか？
Marina：冒頭でお話したように、私たちにとって重要なことはSolana固有の方法でトランザクションを実行できること、つまり並列処理が行えることです。逐次処理をすると、並列実行に比べて不利になるのは間違いありません。私たちがこの問題に取り組んだとき、重要だったのは、Dappsにトランザクションを並列実行する機会を与えることでした。
James：えっとね、チャットから良い質問を頂いたよ。それは、なんでSolanaにEVMを持ち込んだのかという質問です。質問者さん曰く,EVMを介してNenoはSolanaプロトコルに何をもたらすのでしょうか？
Anatory：そうだね、なんでなんですか？？（笑）
Marina：そうですよね、、その部分については私たち自身もすごく議論した内容なのですが、Neon EVMはブリッジではありません。EthereumからSolanaに資金に移すのではなく、Solana上でSolidityのコントラクトを処理できるようにすることが重要なんです。これがNeon EVMがブロックチェーンに空間にもたらすものです。そうは言っても、EthereumからSolanaへトークンを送るためには、ブリッジを介さなければなりません。そのため今後ブリッジとの統合を行うつもりです。
Anatory：現実的には、LinuxやBSD、Windowsのような環境を作ることができると思います。Solanaは、コードを実行する独自の奇妙な方法を持つオペレーティングシステムです。でも、一般的なコードも実行することもできますよ。実際、実行されるコードは、Linuxにあるような実行ファイルのように見えますが独自のものになっているだけです。この移行は、EVMをLinuxのx86からWindowsのx86やsolana BPFに移行するのと変わらないと思います。このようなインフラを、新しい言語や環境で再構築するのはとても大変なことです。しかし、EVMがあれば、それを使って他のすべてのものが稼働しているのと同じOS、同じコンピュータで実行することができ、Solana上でも実行できるということです。並列処理を可能にするための設計にどれだけの技術的努力が払われたか。本当に素晴らしいことだと思います。
（※11:21のあたりからアナトリーが話している内容です。ただ、雰囲気理解しかできず、、、ご自身で聞かれた方が正確です。すみません）
James：他の質問にもいいモノがありました。彼の質問は、EVMはSolanaのDappsと、どう互換性があるのか、例えばSerumオーダーブックでもそれを使うことができるのか？という質問です。
Anatory：そうですね、これは同じステートマシーンで動作しているので、、JavaがWindowsのAPIにアクセスできるように、Serumにもアクセスできますし、他のすべてのAPIにもアクセスできます。でも、これはちょっと面倒な作業になります。新しいWindows APIにアクセスするためにJavaから書かなければならないのと同じくらいの作業になるんです。なので、プロキシやサイドチェーン、あるいは他の人の鍵を使ってロックする必要はないんです。なので純粋なトラストレスなんです。でも、こういう仕事って楽しいモノじゃないですよね、、。だからエンジニアの力仕事みたいなもんです。誰かがやらなきゃいけないんですよね（笑）多分Semenがやってくれるよ（笑）
Marina：So if you want to run your solidity contracts or on your Neon EVM and want to write some functions, access is some applications built on natively on Solana. definitely you need to write down in your code, the this function says to call functions 10 (?), this is these actions.
Anatory：トリッキーな部分として、、Neonは複数のブロックを処理できるインクリメンタルコンピュテーションをサポートしていますよね、それがもし最終的に計算が失敗しSolanaの状態遷移のようにアトミックにコミットされるものもあり、この2つの状態を扱うにはかなりの注意が必要ですね。このようなアプリケーションでは、原子のように分割したいこともあるでしょう。それはすべて可能です。ただ、作業が多いだけです。
（※15：15のあたりからアナトリーが話している内容です。ただ、雰囲気理解しかできず、、、ご自身で聞かれた方が正確です。すみません）
James：よし、じゃあ次の質問ではもう少し深くアーキテクチャについて聞きたいとの声がありますので、もう少しアーキテクチャに踏み込んでもいいかもしれません。その方が理解が深まると思います。
Semen：私が説明しますね…。NeonEVMはSolana上で実行されます…。それにユーザーにサービスを提供するために互換性を大事にしています…。。ユーザーがNeon EVMに接続するためには、Neon Webに接続するためのNeonプロキシの3つのプロンプトを使用するか、またはユーザーがそれを必要としない場合は、Metamaskのように任意のものを使用することができます。 ユーザーがMetamaskでトランザクションを作成するときには、ほとんどの記号トランザクションは、プライベートキーを使用して、プロキシに送信されます…。
（※16：30のあたりからシモンが話している内容です。ただ、雰囲気理解しかできず、、、ご自身で聞かれた方が正確です。すみません）
Anatory：例を出してみよう。例えば、ユーザーAからユーザーBへの送金したいと考えます。そして、別のユーザーがユーザーBへの送金します。そのときには、同じERC-20ですね。つまり、2つの送金が同じ状態で行われているわけです。仮に特定の送金が高額で、なんどもSolana上で取引を行わなければならない人がいるとします。その場合EVMはどのようにこの問題を解決するのでしょうか？
Semen：この場合、トランザクション処理自体は並列処理を行うつもりです。
Anatory：もし、プロキシが失敗したり、2つのプロキシが衝突したりした場合、チェーン上で何が起こるのでしょうか？
Semen：if transaction view executing one iteration, then Solana core, we'll order such transaction. If we can execute in one iteration in switch to multi interactive execution around Neon EVM proxy, we were reorder transaction but no need to look account which involves in false transaction. So we second transaction you're on and you're just finished.
（※20：57のあたりからシモンが話している内容です。力つきました。多分こんなこと話してるけど、、、理解不能。）
Anatory：要は、、2回目のトランザクションで誰かが初期化しようとすると、その初期化は失敗するんですよね。じゃあ、この質問に対して私が理解しているのは、Postgreのような伝統的なデータベースのように、長時間実行されるジョブを導入すると、データベースはそのジョブが完了するまでアカウントをロックすることができるということです。ここでも同様に、EVMにジョブを投入すると、論理的にはロックされます。誰かが2つ目のトランザクションを送信しようとすると、基本的に失敗することになりますが、プロキシはそれが完了するまで遅延させてからアップロードすることができるということです。他に何か質問ありますか？
James：質問の中にトークノミクスについてありました。Neonが稼働すればNeonトークンが使用できます、それにホワイトペーパーの中でもトークンを用意することを書いていますが詳細についてはまだ決まっていないので、今後期待しておいてください。
Marina：それに加えて、私が考えているのはNeonトークンはガバナンストークンとしてのみ実装する予定です。ユーザーはERC-20トークンでもプロキシを運営しているオペレーターにはSolanaトークン、SPLトークンでも支払うことができます。とにかくNeonトークンは単なるガバナンストークンとしての役割を持ちます。
Anatory：それはつまり、ガス代に対してどんなトークンでも支払うことができるということですか？
Marina：ええ、100％互換性があるので。つまり、Neon EVMネットワークを選択して、消費者レベルで、メタマスク環境で自然に動作するように支払えばいいわけです。
James：あー、ブリッジに関する質問がありました。プロトコルにクロスチェーンリクイディティの計画がありますか？というものでした
Anatory：それは、ワームホールというブリッジがあって、そこにSPLトークンであるアセットを、イーサリアムんい通すことができ、SPLトークンと対話するための配管を行うERC20インターフェイスがあると思うのですが、そういうことですか？
Semen：Neon EVM におけるSolidityコントラクトの内部で、SPLトークンの残高を生み出すコントラクトでERC-20を使うことができます…。
Anatory：それが逆にどう機能するか考えたことはありますか？ERC 20トークンをネオンの中で定義した場合 ソラナ上でのメンテナンスはどうするのでしょうか？
Marina：（※26：26のあたりからMarinaが話している内容です。音キレすぎて断念）
Semen：（※26：47のあたりからシモンが話している内容です。）
Anatory：ブリッジというのは、、、私がERC-20やSPLトークンを持っていて、それをラッピングしてブリッジできるほどにスマートなものなのでしょうか？それに、それをちゃんともとに戻すことができるのでしょうか？（笑）
Marina：（※27：52のあたりからMarinaが話している内容です。英語話してる、、、？誰か助けてｗ）
Anatory：良い質問ありました。イーサリアムベースで稼働しているアプリケーションをNeonで動作させるには、どのくらいの時間がかかりますか？
Marina：それはのデプロイメントスキルによります（笑）もし、アプリケーションのデプロイ方法を知っているなら、ぜひNeonにデプロイしてみてください。私たちはuniswapアプリケーションで、この作業を行ったのですが、uniswapアプリケーションをよく知らずやってしまったので、適切なデプロイ方法を見つけ出さなければならず、かなり時間がかかってしまいました。（笑）
James：もう一つの質問として、前にも取り上げたかもしれませんがSerumのオーダーブックのようなものと、ユニスワップはある程度強豪関係にあると思います。現在おおくのユーザーは互換性のあるサイドチェーンやL2を手に入れ、その存在はユーザーを喜ばせることができていると思います。そこでSolanaとイーサリアムでは現在別々ですが、新しいマーケットとしてアクセスできるし、他のネイティブなDappsと組み合わせることもできるというのは、一種のプロの所業だと思います。
他の質問は、、、 ツールキットの中で互換性のないものはありますか？というものです。私が考えるに、イーサリアムベースの開発ツールのように、Neonと互換性がないものを指しているのではないでしょうか？
Semen：Neon EVMにおいてどんなツールキットもサポートする予定です。
Marina：すべてうまくいくはずなので、もし何かあればすぐに知らせてくれたらすぐに修正しますよ。
James：プロジェクトのタイムスケジュールについての質問が来ていますが、既にテストネットは行っています。メインネットの切り替えは9月中、または9月下旬を予定しています。
Anatory：そうだね、他にもいろんな監査やディスカッションがあるかもしないけど
Marina：私たちのスマートコントラクトセットの重要な監査で、オンボードの準備ができているわ
Anatory：難しい質問をするけど、もしイーサリアムに新しい機能性が搭載されたするように変更がかかったらどうするつもり？
Marina：あー！それはすごくシンプルな質問だよ！だってそのことについて昔よく考えていたから。数年間の間異なるブロックチェーンで運営していたから、そのときにハードフォークっていう問題が発生して、私たちの場合、Neon EVMのコントラクトを更新していたの。それでいまは。分散型のガバナンスにより、これらの更新が改善され、チームが最新のEVMに対応できるようになっているの
Anatory：EVM v1とEVM v2を用意して人々に正しく移行してもらうのではなく、現在稼働しているバイナリを更新することになると思いますが、その場合はコードを直接更新することになります。
Semen：Neon EVMのプログラムをSolana上でアップデートすることができます（35：40あたりからMarinaとSemenが英語でない言語で話しています。Marinaが、ロシア語/英語/ドイツ語/フランス語のバイリンガルなのでその言語のどれかかと、、聞いたことがないのでロシア語のような気もしますが。）
Anatory：アップデートがあるならガバナンスの投票によってバイナリコードの直接更新が行われることになるんですね、了解
Semen：ごめんなさい、時々ロシア語に切り替えなきゃいけなくて（笑）
（やっぱりロシア語で話していたみたいです）
Anatory：大丈夫だよ、Solanaもロシア語を勉強しないとだね（笑）
James：あー少し戻って質問に、SolanaのネイティブユーザーがSolanaのアドレスからNeon uniwapを使ってその感想を聞きたいそうです。
Anatory：それは私が答えるよ。これは少々複雑になりそうですね。Phantomのようなネイティブユーザーとしてのウォレットは、あなたがそこでトランザクションに署名するとき、そのトランザクションは、ウォレットが署名する内容を理解しなければならないからです。つまり、実際には、イーサリアムフォーマットのデータのようなコードでイーサリアムを送信していることを知らなきゃいけなくて、そのデータを生成して、EVM互換の署名をしなければなりません。そのため、ウォレットであるPhantomが直接サポートできるように追加する必要があります。これはおそらく、世界中のすべてのウォレットに起こることだと思いますが、solanaに加えて何らかの形でeイーサリアムの互換性をサポートするようなことが必要になります。
Semen：その点ついては、Phantomとは話をしていたんです。彼らは、機能を提供するという点では独自のパイプラインを持っていて、私たちののことは知ってくれているので、うまくいけばこの互換性が実現すると思ってるわ。
Anatory：イーサリアムは一切の実行を行わない予定だそうです。。データの可用性と不正行為の証明を提供するためだけに存在しているようなものです。しかし、それでも実行層は必要ですよね。誰かがイーサリアムのトランザクション処理しなきゃいけない。そこで私がNeonを気に入っているのはイーサリアム上であらゆる種類のロールアップを構成し、必要な不正証明を行って、そのすべてを実行環境としてNeonに向けることで、スマートコントラクトとして実行するための理論となりうるからです。それに、非常に高速で高性能な並列処理エンジンの恩恵を受けることができる点です。奇妙な方法ですが、2、3年前に行った設計上の決定のおかげで、イーサリアムとはお互いに2つの大事なピースである、パズルであると思ったんです。
Marina：ERC 721トークンとの統合や互換性についての質問がありますが、NFTやアプリとの互換性を示すためには、標準規格が必要であり、現在は存在していないのではないでしょうか？といことですが、現在ERC-721をサポートしていませんが、将来的にはサポートする予定です。
あ、でもページに関しての質問ですが、ユニスワップのデモは、テストローンチの初日には公開されていました。ユニスワップコントラクト内容も、ユニスワップのインターフェースも何も変えていませんでした。何も変更しなかったので、Googleはフィッシングサイトだと判断しました。そのため、私たちの側でデモページを削除しなければなりませんでした。だから今は、Googleに利用許可を求めるために、インターフェースを作り直しています。その後、すべての準備が整い、私たちのソリューションをユニスワップで遊んでみてテストしています！
Anatory：デモページはもう触れるの？
Marina：いいえ、まだ私たちの方でしかアクセスできないようになっています。っまたインターフェイスを整えている段階です。
James：多分これが最後の質問になると思うけどインフラの一部であるオペレーターを明確にするための質問がありました、
Marina：これらのプロキシは、Neon EVMで実行するトランザクションを準備するために必要なWeb 3サーバです。つまり、イーサリアムトランザクションスタイルを用意し、それをSolanaトランザクションにラップして、並行処理するために必要なすべての作業を行う必要があります。それから、この仕事はプロキシが行います。つまり、ネオンEVMコントラクトが後で実行するトランザクションを準備するのです。つまり、これらのプロキシはNeon EVMオペレータによって導き出されます。しかしプロキシ機能は、クライアントライブラリとして、アプリケーションによって構築することができます。表示します。そして、この場合は、アプリケーションを表示することで、このネオンEVMオペレータの役割を果たします。
（※43：36のあたりからMarinaが話している内容です。文字書き出して翻訳掛けただけなんでわかりずらいです、聞いてください💦）
Anatory：プロキシ自体は信頼できませんが、プロキシが実際に行う、トランザクションに関連する状態を保持するSolanaアカウントを計算し、このトランザクションの実行に含める必要があるということだけです。一方、EVMはEthereum側で動作します。それにもし間違った処理をした場合、全体が失敗し、誰でも再起動できますが、ユーザーには何の負担もかかりません。プロキシが良い仕事をしなければ、トークンをバーンするだけだからです。
James：まだ数分あるので、この質問を取りげてみます。基本にSolanaはNeonやメタマスク、ブリッジを使いたくないと考えていますが、なぜSolanaはレイヤーを重ねるのではなく、Neonを使用すると決めたのでしょうか？
Anatory：Solidityで書かれたイーサリアムを、EVMを使ってデプロイすればアプリケーションである1インチなどからSerumにアクセスできます。そういうことも可能なんです。それにPhantomのようなものからイーサリアムのトランザクションにサインアップするためのサポートは、いずれ実現するでしょう。時間はかかりますが、BinanceスマートチェーンやMaticのような選択肢が増えることで、ユーザーには多くのメリットがあります。直接アクセスしなくても、マーケットメーカーがEVMチェーン内で取引を行い、原子レベルでポジションをゼロに変更することで、事実上、流動性を高めることができるのです。つまり、同じステートマシンの中にいるだけで、その恩恵を受けることができるのです。
James：そうですね！最後にどこにアクセスすれば私たちの進捗状況をフォローできるのか、などをお知らせして終わりにしたいと思っています。皆さん、ご質問ありがとうございました。他にご質問があれば、ツイッターでお問い合わせください。また、より詳細な情報については、Neonウェブサイトをご覧いただきたいと思います。また、テクニカルペーパーやホワイトペーパー、GitHubをご覧になりたい場合は、TwitterやDiscordを含むすべてのリンクが掲載されていますので、お気軽にお問い合わせください。ご意見、ご感想、ご不明な点などございましたら、ぜひお聞かせください。
ありがとうございました。
--------
ほんとテクニカルな面に関しては断念してる部分が多いので、だれが補足していただけるとすごーくうれしいです。
この記事が気に入ったらサポートをしてみませんか？