Dan Finlay氏、Karl Floersch氏、David Hoffman氏、ScrollチームとSoulWalletチームには、フィードバック、レビュー、提案をしていただき、心より感謝いたします。

イーサリアムが若い実験的な技術から、平均的なユーザーにオープンでグローバルでパーミッションレスな体験を実際にもたらすことができる成熟した技術スタックに移行するにつれて、スタックはほぼ同時に3つの主要な技術的移行を受ける必要があります。

• L2 スケーリングの移行 - すべてのユーザー がロールアップに移行する
• ウォレットセキュリティの移行 - 誰もがスマートコントラクトウォレットに移行する
• プライバシーの移行 - プライバシーを保護する送金が利用可能であることを確認し、開発されている他のすべてのガジェット(ソーシャルリカバリー、ID、評判)がプライバシーを保護することを確認します

生態系の遷移トライアングル。 3つのうち3つしか選べません。

前者がいなければ、イーサリアムは各取引のコストが3.75ドル(別の強気相場がある場合は82.48ドル)の費用がかかるため失敗し、マスマーケットを狙うすべての製品は必然的にチェーンを忘れ、すべてに中央集権的な回避策を採用します。

2つ目がなければ、ユーザーは自分の資金(および非金融資産)を保管することに抵抗があるため、イーサリアムは失敗し、誰もが中央集権的な取引所に移行します。

3つ目がなければ、すべてのトランザクション(およびPOAPなど)を文字通り誰でも見ることができるように公開することは、多くのユーザーにとってプライバシーを犠牲にしすぎているため、イーサリアムは失敗し、誰もが少なくともある程度データを隠す中央集権的なソリューションに移行します。

これら 3 つの移行は、上記の理由から重要です。 しかし、それらを適切に解決するためには、激しい調整が必要なため、困難でもあります。 改善する必要があるのはプロトコルの機能だけではありません。場合によっては、イーサリアムとのやり取りの方法を根本的に変える必要があり、アプリケーションやウォレットの大幅な変更が必要になります。

この 3 つの移行により、ユーザーとアドレスの関係が根本的に再構築されます

L2 スケーリングの世界では、ユーザーは多くの L2 に存在することになります。 あなたはOptimismで活動するExampleDAOのメンバーですか? 次に、Optimismのアカウントがあります。 ZkSyncのステーブルコインシステムでCDPを保有していますか? 次に、ZkSyncにアカウントがあります。 カカロットにたまたま住んでいたアプリケーションを試してみましたか? その後、カカロットのアカウントを持っています! ユーザーが1つのアドレスしか持たない時代は終わります。

Brave Walletの見解によると、私は4か所にETHを持っています。 そして、はい、ArbitrumとArbitrumNovaは異なります。 心配しないでください、それは時間の経過とともにより混乱します!

スマートコントラクトウォレットは、L1とさまざまなL2で同じアドレスを持つことをはるかに困難にすることで、複雑さを増します。 現在、ほとんどのユーザーは外部所有のアカウントを使用しており、そのアドレスは文字通り署名の検証に使用される公開鍵のハッシュであるため、L1とL2の間では何も変わりません。 しかし、スマートコントラクトウォレットでは、1つのアドレスを保持することがより困難になります。 アドレスをネットワーク全体で同等にできるコードのハッシュにするために多くの作業が行われてきましたが、特に CREATE2 と ERC-2470シングルトンファクトリは、これを完璧に機能させることは困難です。 一部の L2 (例: 「タイプ4 ZK-EVM」)はEVMと完全に同等ではなく、多くの場合、代わりにSolidityまたは中間アセンブリを使用しており、ハッシュの等価性を妨げています。 また、ハッシュを同等にできる場合でも、キーの変更によってウォレットの所有権が変更される可能性があるため、 他の直感的でない結果が生じます。

プライバシー保護のため、各ユーザーはさらに多くのアドレスを持つ必要があり、扱うアドレスの種類が変わることさえあります。 ステルスアドレスの提案が広く使用されるようになると、各ユーザーが少数のアドレスしか持たないか、L2ごとに1つのアドレスを持つのではなく、ユーザーはトランザクションごとに1つのアドレスを持つ可能性があります。Tornado Cashのような既存のものであっても、他のプライバシースキームは、資産の保管方法を異なる方法で変更します:多くのユーザーの資金は同じスマートコントラクトに(したがって同じアドレスに)保管されます。 特定のユーザーに資金を送金するには、ユーザーはプライバシースキーム独自の内部アドレス指定システムに依存する必要があります。

これまで見てきたように、3つのトランジションはそれぞれ異なる方法で「1人のユーザー~=1つのアドレス」のメンタルモデルを弱め、これらの効果の一部はトランジションの実行の複雑さにフィードバックされます。 特に複雑な点は、次の 2 つです。

1. 誰かに支払いたい場合、支払い方法に関する情報をどのように入手しますか?
2. ユーザーがさまざまなチェーンのさまざまな場所に多くの資産を保管している場合、重要な変更と ソーシャルリカバリーをどのように行うのでしょうか?

3つの移行とオンチェーン決済(およびID)

スクロールにコインを持っていて、コーヒー代を払いたいです(「私」が文字通りこの記事の筆者である私である場合、「コーヒー」はもちろん「緑茶」の換喩です)。 あなたは私にコーヒーを売っていますが、太鼓でコインを受け取るようにしか設定されていません。 ワットか?

基本的に2つの解決策があります。

1. 受取側のウォレット(マーチャントの場合もあれば、一般の個人の場合もある)は、すべてのL2をサポートするために懸命に努力し、資金を非同期で統合するための自動化された機能を持っています。
2. 受取人は自分のアドレスと一緒にL2を提供し、送金者のウォレットはクロスL2ブリッジングシステムを介して宛先L2に資金を自動的にルーティングします。

もちろん、これらのソリューションを組み合わせることもできます:受信者は受け入れる意思のあるL2のリストを提供し、送信者のウォレットは、運が良ければ直接送信するか、そうでなければクロスL2ブリッジングパスのいずれかを含む支払いを計算します。

しかし、これは 3 つの移行がもたらす重要な課題の一例にすぎません: 誰かに支払うような単純なアクションには、20 バイトのアドレスだけでなく、はるかに多くの情報が必要になります。

スマートコントラクトウォレットへの移行は、幸いなことにアドレッシングシステムにとって大きな負担にはなりませんが、アプリケーションスタックの他の部分には、解決すべき技術的な問題がまだいくつか残っています。 ウォレットは、トランザクションとともに21000ガスしか送信しないように更新する必要があり、ウォレットの支払い受取側がEOAからのETH送金だけでなく、スマートコントラクトコードによって送信されたETHも追跡するようにすることがさらに重要になります。 アドレスの所有権が不変であるという前提に依存しているアプリ(例: ロイヤリティを強制するためにスマートコントラクトを禁止するNFT)は、目標を達成するための他の方法を見つける必要があります。 スマートコントラクトウォレットは、特に、ETH以外のERC20トークンのみを受け取った場合、 ERC-4337ペイマスター を使用してそのトークンでガス代を支払うことができます。

一方、プライバシーは、私たちがまだ実際に対処していない大きな課題を再び提起しています。 オリジナルのTornado Cashは、内部送金をサポートしていなかったため、これらの問題は発生しませんでした:ユーザーはシステムに入金して、そこから引き出すことしかできませんでした。 ただし、内部転送を行うことができるようになると、ユーザーはプライバシー システムの内部アドレス指定スキームを使用する必要があります。 実際には、ユーザーの「支払い情報」には、(i) ある種の「支出パブキー」、つまり受信者が使用に使用できる秘密へのコミットメント、および (ii) 受信者が支払いを発見できるように、受信者のみが復号化できる暗号化された情報を送信者が送信する方法の両方が含まれている必要があります。

ステルスアドレスプロトコルは 、メタアドレスの概念に依存しており、メタアドレスの一部は送信者の支出キーのブラインドバージョンであり、別の部分は送信者の暗号化キーです(ただし、最小限の実装では、これら2つのキーを同じに設定できます)。

暗号化とZK-SNARKに基づく抽象的なステルスアドレス方式の概略図。

ここでの重要な教訓は、プライバシーに配慮したエコシステムでは、ユーザーは支出用公開鍵と暗号化公開鍵の両方を持ち、ユーザーの「支払い情報」には両方の鍵を含める必要があるということです。 また、支払い以外にも、この方向に拡大する正当な理由があります。 たとえば、イーサリアムベースの暗号化された電子メールが必要な場合、ユーザーは何らかの暗号化キーを公開する必要があります。 「EOAの世界」では、このためにアカウントキーを再利用することができますが、安全なスマートコントラクトウォレットの世界では、おそらくこのためのより明示的な機能を持つ必要があります。 これは、イーサリアムベースのIDを、イーサリアム以外の分散型プライバシーエコシステム、特にPGPキーとの互換性を高めるのにも役立ちます。

3 つの移行とキーの回復

ユーザーごとに多数のアドレスが存在する世界でキーの変更とソーシャル回復を実装する既定の方法は、ユーザーが各アドレスで個別に回復手順を実行することです。 これはワンクリックで行うことができます:ウォレットには、ユーザーのすべてのアドレスで同時に回復手順を実行するソフトウェアを含めることができます。 ただし、このようなUXの簡素化を行っても、ナイーブなマルチアドレスリカバリには3つの問題があります。

1. ガス代の非実用性:これは一目瞭然です。
2. 反事実アドレス:スマートコントラクトがまだ公開されていないアドレス(実際には、これはまだ資金を送金していないアカウントを意味します)。 ユーザーとしてのあなたは、潜在的に無制限の数の反事実アドレスを持っています:まだ存在しないL2を含むすべてのL2に1つ以上、およびステルスアドレススキームから生じる反事実アドレスの他のすべての無限のセット。
3. プライバシー:ユーザーが意図的に多くのアドレスを持っていて、それらを相互にリンクしないようにしている場合、彼らは確かにそれらを同時に、またはほぼ同時に回復することによってそれらすべてを公にリンクしたくありません!

これらの問題を解決するのは困難です。 幸いなことに、それなりにうまく機能する、やや洗練されたソリューション、つまり検証ロジックと資産保有を分離するアーキテクチャがあります。

各ユーザーには、1 つの場所 (メインネットまたは特定の L2) に存在するキーストア コントラクトがあります。 その後、ユーザーは異なる L2 にアドレスを持ち、それらの各アドレスの検証ロジックはキーストア コントラクトへのポインタになります。 これらのアドレスから支出するには、現在(またはより現実的にはごく最近の)支出公開鍵を示す証明をキーストアコントラクトに入力する必要があります。

証明はいくつかの方法で実装できます。

• L2 内の読み取り専用 L1 への直接アクセス。 L2 を変更して、L1 の状態を直接読み取る方法を提供することができます。 キーストア コントラクトが L1 にある場合、L2 内のコントラクトはキーストアに「無料で」アクセスできることを意味します
• マークルの枝。 マークル分岐は、L1 状態を L2 に証明したり、L2 状態を L1 に証明したり、この 2 つを組み合わせて、ある L2 の状態の一部を別の L2 に証明したりできます。 マークル証明の主な弱点は、証明の長さによるガスコストの高さです:証明には5 kBの可能性がありますが、 これはVerkleツリーのために将来的には<1 kBに減少します。
• ZK-SNARKsです。 ブランチ自体ではなく、MerkleブランチのZK-SNARKを使用することで、データコストを削減できます。 オフチェーンアグリゲーション技術( EIP-4337など)を構築して、1つのZK-SNARKでブロック内のすべてのクロスチェーン状態証明を検証することができます。
• KZGのコミットメント。 L2、またはその上に構築されたスキームは、逐次アドレス指定システムを導入し、このシステム内の状態証明をわずか48バイトの長さにすることができます。 ZK-SNARKと同様に、 マルチプルーフスキーム では、これらすべてのプルーフをブロックごとに1つのプルーフにマージすることができます。

トランザクションごとに 1 つのプルーフを作成するのを避けたい場合は、回復のために L2 間のプルーフのみを必要とする、より軽いスキームを実装できます。 アカウントからの支出は、対応する公開鍵がそのアカウント内に格納されている支出キーに依存しますが、復旧には、キーストア内の現在のspending_pubkeyをコピーするトランザクションが必要です。 反事実的アドレスの資金は、古いキーがそうでなくても安全です:反事実的アドレスを「アクティブ化」して有効な契約に変えるには、現在のspending_pubkeyをコピーするためのクロスL2プルーフを作成する必要があります。 Safeフォーラムのこのスレッドでは、 同様のアーキテクチャがどのように機能するかを説明しています。

このようなスキームにプライバシーを追加するには、ポインタを暗号化するだけで、ZK-SNARK内ですべての証明を行います。

より多くの作業(例: <a href="https://notes.ethereum.org/@vbuterin/non_index_revealing_proof">this を使用します。 出発点として)、ZK-SNARKの複雑さのほとんどを取り除き、より必要最低限のKZGベースのスキームを作成することもできます。

これらのスキームは複雑になる可能性があります。 プラス面としては、それらの間に多くの潜在的な相乗効果があります。 たとえば、「キーストアコントラクト」の概念は、前節で述べた「アドレス」の課題に対する解決策にもなり得ます:ユーザーが鍵を更新するたびに変更されない永続的なアドレスをユーザーに持たせたい場合は、ステルスメタアドレス、暗号化鍵、およびその他の情報をキーストアコントラクトに入れ、キーストアコントラクトのアドレスをユーザーの「アドレス」として使用できます。

多くのセカンダリ インフラストラクチャを更新する必要がある

ENS の使用にはコストがかかります。 2023年6月の現在、状況はそれほど悪くなく、取引手数料は高額ですが、それでもENSドメインの手数料に匹敵します。 zuzalu.ethの登録には 約27ドルかかり、そのうち11ドルは取引手数料でした。 しかし、別の強気相場があれば、手数料は急騰します。 ETHの価格が上昇しなくても、ガス料金が200gweiに戻ると、ドメイン登録のTX料金が104ドルに上昇します。 したがって、特にユーザーがほぼ無料の登録を要求する分散型ソーシャルメディアのようなユースケースで、人々に実際にENSを使用してもらいたい場合(これらのプラットフォームはユーザーにサブドメインを提供しているため、ENSドメイン料金は問題になりません)、L2で動作するENSが必要です。

幸いなことに、ENS チームはステップアップし、L2 での ENS が実際に行われています。 ERC-3668 (別名「CCIP標準」) は、 ENSIP-10 とともに、任意の L2 上の ENS サブドメインを自動的に検証可能にする方法を提供します。 CCIP標準では、L2上のデータの証明を検証する方法を記述したスマートコントラクトと、ドメイン(例: Optinames は ecc.eth を使用します) は、そのようなコントラクトの管理下に置くことができます。 CCIP コントラクトが L1 の ecc.eth を制御すると、一部の subdomain.ecc.eth にアクセスすると、自動的に証明の検索と検証が必要になります (例: マークルブランチ)は、その特定のサブドメインを実際に保存するL2の状態です。

実際に証明を取得するには、コントラクトに保存されているURLのリストにアクセスする必要がありますが、これは確かに中央集権化のように感じられますが、実際にはそうではないと主張します:これは 1-of-N信頼モデル です(無効な証明はCCIPコントラクトのコールバック関数の検証ロジックによって捕捉され、URLの1つでも有効な証明が返される限り、 あなたは良いです)。 URL のリストには、数十の URL が含まれる場合があります。

ENS CCIPの取り組みはサクセスストーリーであり、私たちが必要とする抜本的な改革が実際に可能であることの表れと見なされるべきです。 しかし、アプリケーション層の改革は、まだまだたくさんあります。 いくつか例を挙げます。

• 多くのDAppsは、ユーザーがオフチェーンの署名を提供することに依存しています。 外部所有アカウント (EOA) を使用すると、これは簡単です。 ERC-1271 は、スマートコントラクトウォレットにこれを行うための標準化された方法を提供します。 しかし、多くのDAppsはまだERC-1271をサポートしていません。彼らはそうする必要があります。
• 「これはEOAですか?」を使用してユーザーと契約を区別する(譲渡の防止やロイヤリティの強制など)DAppsは壊れます。 一般的に、ここで純粋に技術的な解決策を見つけようとしないことをお勧めします。暗号制御の特定の譲渡が受益所有権の譲渡であるかどうかを見極めることは難しい問題であり、おそらく オフチェーンのコミュニティ主導のメカニズムに解決しない限り解決できません。 ほとんどの場合、アプリケーションは転送の防止にあまり依存せず、 ハーバーガー税などの手法に頼らざるを得なくなるでしょう。
• ウォレットが支出や暗号化キーとどのように相互作用するかを改善する必要があります。 現在、ウォレットはアプリケーション固有の鍵を生成するために決定論的署名を使用することが多く、EOAの秘密鍵で標準のノンス(アプリケーション名のハッシュなど)に署名すると、秘密鍵なしでは生成できない決定論的な値が生成されるため、純粋に技術的な意味で安全です。 ただし、これらの手法はウォレットに対して「不透明」であり、ウォレットがユーザーインターフェイスレベルのセキュリティチェックを実装するのを妨げます。 より成熟したエコシステムでは、署名、暗号化、および関連する機能は、ウォレットによってより明示的に処理する必要があります。
• ライトクライアント(例: ヘリオス)L1だけでなく、L2も検証する必要があります。 現在、ライト クライアントは、L1 ヘッダーの有効性チェック ( ライト クライアント同期プロトコルを使用) と、L1 状態の Merkle ブランチと L1 ヘッダーをルートとするトランザクションの検証に重点を置いています。 明日は、L1 に格納されている状態ルートをルートとする L2 状態の証明も検証する必要があります (これのより高度なバージョンでは、実際には L2 の事前確認を調べます)。

ウォレットは、資産とデータの両方を保護する必要があります

今日、ウォレットは資産を保護するビジネスを行っています。 すべてがオンチェーンで存在し、ウォレットが保護する必要があるのは、現在それらの資産を保護している秘密鍵だけです。 キーを変更した場合は、翌日に以前の秘密キーをインターネットに安全に公開できます。 しかし、ZKの世界では、これはもはや真実ではなく、ウォレットは認証資格情報を保護するだけでなく、データも保持しています。

そのような世界の最初の兆候は、Zuzaluで使用されていたZK-SNARKベースのIDシステムである Zupassで見られました。 ユーザーは、システムへの認証に使用する秘密鍵を持っていて、それを使って「私がZuzaluの居住者であることを証明しなさい。どれかは明かさずに」といった基本的な証明をすることができます。 しかし、Zupassシステムには、他のアプリ、特にスタンプ(ZupassのPOAPバージョン)も構築され始めました。

私の多くのZupassスタンプの1つで、私がチームキャットの誇り高いメンバーであることを確認しています。

POAPよりも切手が優れている主な特徴は、切手がプライベートであることです:データをローカルに保持し、誰かにあなたに関する情報を持たせたい場合にのみ、スタンプ(または切手に対する計算)をZK証明します。 しかし、これは追加のリスクを生み出します:その情報を失うと、スタンプを失うことになります。

もちろん、データを保持するという問題は、単一の暗号化キーを保持するという問題に還元できます:何らかの第三者(またはチェーン)がデータの暗号化されたコピーを保持することができます。 これには、実行するアクションによって暗号化キーが変更されないため、暗号化キーを安全に保持しているシステムとの対話が不要になるという便利な利点があります。 しかし、それでも、暗号化キーを紛失すると、すべてが失われます。 反対に、誰かがあなたの暗号化キーを見ると、そのキーに暗号化されたすべてのものが表示されます。

Zupassの事実上の解決策は、人々が自分の鍵を複数のデバイスに保存することを奨励することでした(例: ラップトップと電話)、すべてのデバイスに同時にアクセスできなくなる可能性はごくわずかです。 さらに進んで、 シークレット共有 を使用してキーを保存し、複数のガーディアンに分割することもできます。

MPCによるこの種の社会的回復は、現在の保護者だけでなく、以前の保護者も共謀して資産を盗む可能性があり、許容できないほど高いリスクであるため、ウォレットにとって十分な解決策ではありません。 しかし、プライバシーの漏洩は一般的に資産の損失よりもリスクが低く、プライバシーの要求が高いユースケースを持つ人は、プライバシーを要求するアクションに関連するキーをバックアップしないことで、損失のリスクが高くなります。

複数の復旧経路を持つビザンチンシステムでユーザーを圧倒することを避けるために、ソーシャルリカバリをサポートするウォレットは、資産のリカバリと暗号化キーのリカバリの両方を管理する必要があるでしょう。

アイデンティティに戻る

これらの変化に共通する点の1つは、オンチェーンで「あなた」を表すために使用する暗号識別子である「アドレス」の概念を根本的に変えなければならないということです。 「私との対話方法の指示」は、もはや単なるETHアドレスではありません。それらは、何らかの形で、複数のL2上の複数のアドレス、ステルスメタアドレス、暗号化キー、およびその他のデータの組み合わせである必要があります。

これを行う1つの方法は、ENSをあなたのアイデンティティにすることです:あなたのENSレコードは、これらの情報をすべて含めることができ、あなたが誰かにbob.eth(またはbob.ecc.eth または...)、より複雑なクロスドメインやプライバシー保護の方法を含め、支払い方法やあなたとのやり取りに関するすべてを調べて見ることができます。

しかし、このENS中心のアプローチには2つの弱点があります。

• それはあなたの名前にあまりにも多くのものを結びつけます。 あなたの名前はあなたではなく、あなたの名前はあなたの多くの属性の1つです。 ID プロファイル全体を移動したり、多くのアプリケーションで多数のレコードを更新したりすることなく、名前を変更できる必要があります。
• 信頼できない反事実的な名前を持つことはできません。 ブロックチェーンの重要なUX機能の1つは、チェーンとまだやり取りしていない人々にコインを送ることができることです。 このような機能がなければ、落とし穴22があります:チェーンと対話するには、取引手数料を支払う必要があり、それには...すでにコインを持っています。 CREATE2付きのスマートコントラクトアドレスを含むETHアドレスには、この機能があります。 ENS 名は、2 つの Bob が両方ともオフチェーンで bob.ecc.eth であると判断した場合、 どちらに名前を付けるかを選択する方法はありません。

考えられる解決策の 1 つは、この記事で前述したアーキテクチャで説明したキーストア コントラクトにさらに多くのものを入れることです。 キーストアコントラクトには、ユーザーに関するさまざまな情報とユーザーとのやり取り方法がすべて含まれており(CCIPでは、その情報の一部がオフチェーンである可能性があります)、ユーザーはキーストアコントラクトをプライマリ識別子として使用します。 しかし、彼らが受け取る実際の資産は、あらゆる種類の異なる場所に保管されます。 キーストア コントラクトは名前に縛られず、事実に反する可能性が高くなります: 特定の固定の初期パラメータを持つキーストア コントラクトによってのみ初期化できることが証明可能なアドレスを生成できます。

別のカテゴリのソリューションは、 ビットコイン支払いプロトコルと同様の精神で、ユーザー向けアドレスの概念を完全に放棄することと関係があります。 1 つのアイデアは、送信者と受信者の間の直接的なコミュニケーション チャネルに大きく依存することです。たとえば、送信者は請求リンクを(明示的なURLまたはQRコードとして)送信し、受信者はそれを使用して支払いを好きなように受け入れることができます。

送信者と受信者のどちらが先に行動するかに関係なく、最新の支払い情報をリアルタイムで直接生成するウォレットへの依存度が高まると、摩擦を減らすことができます。 そうは言っても、永続的な識別子は (特に ENS では) 便利であり、送信者と受信者の間の直接通信の仮定は実際には非常にトリッキーなものであるため、さまざまな手法の組み合わせが見られる可能性があります。

これらすべての設計において、分散化され、ユーザーが理解しやすい状態を維持することが最も重要です。 ユーザーが現在の資産と、自分宛ての公開メッセージに関する最新のビューに簡単にアクセスできるようにする必要があります。 これらのビューは、プロプライエタリなソリューションではなく、オープンなツールに依存する必要があります。 決済インフラの複雑さが不透明な「抽象化の塔」に変わり、開発者が何が起こっているのかを理解し、それを新しいコンテキストに適応させるのに苦労するのを防ぐには、大変な努力が必要です。 課題はあるものの、一般ユーザーのスケーラビリティ、ウォレットのセキュリティ、プライバシーを実現することは、イーサリアムの将来にとって非常に重要です。 技術的な実現可能性だけでなく、一般ユーザーにとっての実際のアクセシビリティも重要です。 私たちはこの課題に立ち向かう必要があります。

免責事項：

1. この記事は[vitalik]から転載されており、すべての著作権は原作者[Vitalik Buterin]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。