banner
leaf

leaf

It is better to manage the army than to manage the people. And the enemy.
follow
substack
tg_channel

加密ビジネスモデルと防御能力

暗号ビジネスモデルと防御能力
提案者
アンドリーセン・ホロウィッツ・アリ・イェハヤ

この内容は参考のためのものであり、法律、ビジネス、投資、または税務のアドバイスとして使用されるべきではありません。
これらの事柄については、自分自身のアドバイザーに相談するべきです。証券、デジタル資産、トークン、及び / または暗号通貨に関する言及は、説明の目的のみであり、これらのツールへの投資アドバイスを構成するものではなく、投資アドバイスサービスの提供のオファーを構成するものではありません。さらに、この内容は、いかなる投資家または潜在的な投資家を対象としておらず、いかなる投資家または潜在的な投資家によって使用されることを意図しておらず、a16z が管理するいかなるファンドへの投資を決定する際に、いかなる場合でもこの内容に依存すべきではありません。(a16z ファンドへの投資のオファーは、プライベートプレースメントメモ、サブスクリプション契約、およびそのようなファンドに関連するその他の文書を通じてのみ行われ、完全に読むべきです。)言及、言及または説明された投資またはポートフォリオ会社は、ā16z が管理する投資ツールのすべての投資を代表するものではなく、これらの投資が利益を上げることを保証するものではなく、将来行われる他の投資が類似の特徴または結果を持つことを保証するものではありません。アンドリーセン・ホロウィッツが管理するファンドの投資リスト(発行者が 16z に公開を許可していない投資および公開取引されているデジタル資産への未公開投資を除く)は、https:/al6z.com/investments/ で入手できます。

image

image

image

image

image

image

image

資金調達と取引構造:暗号スタートアップの考慮事項

image

image

image

image

image

この記事が多くの人に困惑を引き起こしているのは、皆がイーサリアムと Hyperledger が現在アカウントモデルに基づいており、UXTO の概念がないことを知っているからです。しかし、著者は記事の中で Hyperledger が UTXO に切り替えたと指摘し、イーサリアムも追加を検討していると述べていますが、これは一体どういうことなのでしょうか。

まず、Hyperledger fabric について言及します。fabric にはトークンすらありません(ビットコインにはビットコインがあり、イーサリアムにはイーサがある)。UTXO について言うのは無意味です。fabric1.0 の全コードを調べても、chaincode の例の中で UTXO に関する内容をいくつか見つけただけで、それはビットコインの UTXO のストレージ機能を chaincode で実現したものであり、単なるスマートコントラクトの例に過ぎません。

では、なぜ著者は fabric が UTXO に切り替えたと言ったのでしょうか?ネットを調べると、確かに関連する内容が見つかりました。一つは ConsenSys の記事で、冒頭の一文は次の通りです:Recently there has been a proposal to have UTXO based architecture as the fabric of the Hyperledger project.(URL:https://medium.com/@ConsenSys/thoughts-on-utxo-by-vitalik-buterin-2bb782c67e53#.sttqvpfqe)。

もう一つはデジタル資産会社(Digital Asset Holdings)の記事で、そこには次のように書かれています:We are also switching from our simplistic notion of accounts and balances to adopt to de facto standard of the Bitcoin UTXO model, lightly modified.(URL:https://digitalasset.com/press/hyperledger-beta-retired.html)

これらは著者の見解を裏付けるように見えます。しかし、実際にはそうではありません。なぜなら、これらの 2 つの記事は古いもので(2016 年 3 月)、その時点では確かにそのような提案や議論がありました。そして、現在のコードには UTXO が全く存在せず、すべてのコードと作業モデルは依然としてアカウントモデルです。ネット上でさらに探すと、Reddit の投稿でこの件に関する議論が見つかりました:Both Vitalik and ConsenSys do indeed believe that UTXO is unnecessarily complicated to serve as the Hyperledger fabric.

したがって結論は、fabric の UTXO はかつての議論に過ぎず、現在 fabric 1.0 には実装されていないということです。また、今後追加する場合は、まず fabric に独自のトークンを導入する必要があります。私の個人的な見解では、fabric は商用スマートコントラクトシステムの設計において、アカウントモデルの方が適していると思います。

次に、イーサリアムの UTXO について話します。イーサリアムは確かに UTXO の導入を検討していますが、この UTXO はあの UTXO とは異なります。皆が想像するように、UTXO を使って既存のアカウントモデルを置き換えるわけではありません。まず、イーサリアムはスマートコントラクトのために設計されており、そのアカウントモデルには残高(balance)だけでなく、スマートコントラクトコード、nonce(再送攻撃を防ぐため)、およびカスタムストレージが含まれています。これらを UTXO に置き換えるのは明らかに不適切です。なぜなら、UTXO はそれに適していないからです。ビットコインの UTXO には単純な属性が一つだけあります:残高(balance)。

では、イーサリアムの UTXO は何を指すのでしょうか?それはイーサリアムの別の話題、すなわちシャーディング(Sharding)です。シャーディングはイーサリアムを拡張し、TPS を増加させる有効な方法であり、現在コミュニティで広く議論され、研究されています。現在のイーサリアムの作業モデルは、すべてのノード(例えば、16 万台)で同時にすべての取引を検証するというもので、実際には非常に非効率的で必要のないモデルです。一貫性を保証するために、アドレスの最初の 4 桁に基づいてシャーディングを行うと、すべてのアドレスを 16 の部分に分けることができます。こうすることで、各取引は 1 万台のノードで検証されれば通過できます。もし取引に関与するアカウントが同じ部分にある場合は問題ありませんが、異なる部分に関与する場合は問題が発生します。

異なる部分間の取引問題を解決するために、イーサリアムはレシート(receipt)と呼ばれる作業モデルを設計しました。このレシートのモデルは UTXO に似ているため、イーサリアムの UTXO とも呼ばれています。

この UTXO が現在のアカウントモデルを置き換えることを指しているわけではなく、ビットコインモデルの UTXO になるわけではないので、現在のアカウントモデルに問題がないということではありません!現在のアカウントモデルには確かにいくつかの欠点があります。

イーサリアムにおけるイーサの移転の安全性はビットコインほど高くありません。以下は実際の例です。あるネットユーザーが私に助けを求め、Yobit.net から 258 ETH を取り戻す手助けをしてほしいと言いました。理由は、彼が Yobit.net から云币网アカウントにコインを移転する際に、out of gas エラーが発生したからです。云币网が提供したターゲットアドレスはコントラクトアドレスであり、Yobit.net は外部アドレスだと思っていたため、取引の gasLimit が 21000 に設定され(これはコントラクトアカウントには不十分です)、そのため out of gas の異常が発生しました。コインの移転はキャンセルされましたが、この取引(Transaction)は完了しました。

したがって結論は、fabric の UTXO はかつての議論に過ぎず、現在 fabric 1.0 には実装されていないということです。また、今後追加する場合は、まず fabric に独自のトークンを導入する必要があります。私の個人的な見解では、fabric は商用スマートコントラクトシステムの設計において、アカウントモデルの方が適していると思います。

次に、イーサリアムの UTXO について話します。イーサリアムは確かに UTXO の導入を検討していますが、この UTXO はあの UTXO とは異なります。皆が想像するように、UTXO を使って既存のアカウントモデルを置き換えるわけではありません。まず、イーサリアムはスマートコントラクトのために設計されており、そのアカウントモデルには残高(balance)だけでなく、スマートコントラクトコード、nonce(再送攻撃を防ぐため)、およびカスタムストレージが含まれています。これらを UTXO に置き換えるのは明らかに不適切です。なぜなら、UTXO はそれに適していないからです。ビットコインの UTXO には単純な属性が一つだけあります:残高(balance)。

では、イーサリアムの UTXO は何を指すのでしょうか?それはイーサリアムの別の話題、すなわちシャーディング(Sharding)です。シャーディングはイーサリアムを拡張し、TPS を増加させる有効な方法であり、現在コミュニティで広く議論され、研究されています。現在のイーサリアムの作業モデルは、すべてのノード(例えば、16 万台)で同時にすべての取引を検証するというもので、実際には非常に非効率的で必要のないモデルです。一貫性を保証するために、アドレスの最初の 4 桁に基づいてシャーディングを行うと、すべてのアドレスを 16 の部分に分けることができます。こうすることで、各取引は 1 万台のノードで検証されれば通過できます。もし取引に関与するアカウントが同じ部分にある場合は問題ありませんが、異なる部分に関与する場合は問題が発生します。

異なる部分間の取引問題を解決するために、イーサリアムはレシート(receipt)と呼ばれる作業モデルを設計しました。このレシートのモデルは UTXO に似ているため、イーサリアムの UTXO とも呼ばれています。

この UTXO が現在のアカウントモデルを置き換えることを指しているわけではなく、ビットコインモデルの UTXO になるわけではないので、現在のアカウントモデルに問題がないということではありません!現在のアカウントモデルには確かにいくつかの欠点があります。

イーサリアムにおけるイーサの移転の安全性はビットコインほど高くありません。以下は実際の例です。あるネットユーザーが私に助けを求め、Yobit.net から 258 ETH を取り戻す手助けをしてほしいと言いました。理由は、彼が Yobit.net から云币网アカウントにコインを移転する際に、out of gas エラーが発生したからです。云币网が提供したターゲットアドレスはコントラクトアドレスであり、Yobit.net は外部アドレスだと思っていたため、取引の gasLimit が 21000 に設定され(これはコントラクトアカウントには不十分です)、そのため out of gas の異常が発生しました。コインの移転はキャンセルされましたが、この取引(Transaction)は完了しました。

image

基本的な判断:

まず、現在の状況について基本的な判断を持つ必要があります。現在(2017 年 3 月)は、デジタル通貨の牛市の始まり + 前期段階にあります。これが基本的な判断であり、市場に入る前提です。この結論が覆されるなら、あなたは参加すべきではありません。

準備活動:

市場に入る前に、一定の準備活動が必要です。以下の条件を満たせない場合は、すぐに離れてください:

期限やプレッシャーのない資金(期限がある場合、少なくとも 5 年以上、つまりこのお金を市場に投入して長期間引き出す必要がないこと);

0 レバレッジ(前期の整理を経て、現在のデジタル通貨取引所の大部分は 0 レバレッジです);

長期保有、売買は一度だけ行う(または、ある期間内に建玉し、ある期間内に清算する)。

これらの準備活動を行った場合、次の問題は、何を買うべきかです。

牛市が来ると、基本的にすべてのデジタル通貨が上昇します。特にひどいものでも。現在、十数種類の有名な通貨があり、数百種類の二代目コインや山寨コインがあります。どの品種を選ぶかが投資の鍵であり、筆者は以下の品種にのみ投資すべきだと考えています:

注意:以下は筆者の見解であり、いかなる投資アドバイスとしても使用されるべきではありません。この文章を読んで関連する投資を行う人は、すべてのリスクと結果を自己責任で負うべきであり、筆者は 1 セントの利益も得られず、単に技術と見解を共有するだけです。

1、ビットコイン(bitcoin)

ビットコインはブロックチェーン概念の発祥地であり、最も広範な信頼を築いています。現在のビットコインの価格は場外で 9000 元、場内で 8000 元程度です。筆者はその合理的な価格は約 3 万だと考えています。現在、ますます多くの見解がビットコインがさらなる信頼を築き、デジタルゴールドになると考えています。このような見解を支持する人々は増えており、その中には著名なイーサリアムの創設者である Vitalik(彼の中国語は非常に上手です)もいます。

現在、ビットコインの総時価総額は金の総時価総額の約 0.3% です(金の総時価総額は 8 兆ドル、ビットコインは現在 125 億ドル)。この観点から、ビットコインには広範な上昇の余地があります。

現在、ビットコインの価格がさらに上昇する主な要因は 2 つです:

内因:ビットコインの拡張問題。ビットコインのネットワークは数年間過負荷で運用されており、拡張問題は解決されていません。ビットコインの支払いには高額な手数料が必要で、確認速度が遅いことがその正常な機能に重大な問題を引き起こしています。拡張問題に関して、bitcoin core の隔離証明方案と bitcoin unlimited のブロック制限の引き上げ方案は、いまだに合意に達しておらず、一定の分裂リスクがあります。筆者は隔離証明を支持する傾向があり、ここでもコミュニティ全体の利益を重視し、早期に合意に達することを期待し、呼びかけます!隔離証明が成功裏にアクティブ化されれば、ビットコインの価格は上昇するでしょう!

外因:政策の抑圧と取引所の引き出し制限。この点については多くを語りたくありません。政策の問題は長期間にわたり、コインの価格に影響を与える主要な要因の一つです。

2、イーサリアム(ETH)

イーサリアムの上昇にはあまり疑いの余地がありません。昨年 12 月のビデオで、デジタル通貨の牛市が ETH の上昇を代表するものになると予言し、70 元程度の時に何度も皆に ETH を建玉するよう呼びかけました。なぜなら、その価値は大幅に過小評価されていたからです。今後、ETH は間違いなく千億時価総額のプラットフォームになるでしょう(呼びかけた時点では時価総額は百億でしたが、最近の上昇により時価総額は 200 億に達しました)。

ETH は生まれつき政策の悩みがないことがその利点です。現在、ETH の価格に影響を与える要因は多くが積極的な要因です。例えば:

企業版イーサリアム連合の設立

ENS(イーサリアムドメインシステム)の立ち上げ

PoS の期待

イーサリアムについて言うと、多くの人が ETC について尋ねます。私も何度も自分の見解を述べ、皆に ETC を清算するよう勧めました。個人的には ETC を全く支持せず、徐々に衰退するか、普通の二代目コインになると考えています。

個人的には ETH の合理的な価格は 500-1000 の間だと思います。

3、ZEC(Zcash)

ビットコインやイーサリアムに比べて、Z コインのリスクはやや大きく、その価値の実現にはより長い時間が必要です。しかし、長期的に見れば、その匿名性の価値は人類が普遍的に追求する価値の一つになるでしょう。現在のところ、その欠点も明らかです:

政府に対してより友好的ではない;

技術が成熟しておらず、クライアントのサポートが少なく、大きなメモリと CPU が必要で、匿名取引を送信するのに約 1 分かかる;

隠れたバグや増発の問題が発見できない;

それでも、筆者は 260 程度の価格で皆に建玉するよう呼びかけ、価格が 3000 元に達することを期待しましたが、より長い時間(おそらく 5 年以上)が必要です。

上記のコインの選択は一般的に認められた選択でもあります。実際、皆はビットコインが核心であると考えています。ビットコインが解決できない問題を解決するために生まれた新しいコインだけが生命力を持ちます。例えば、イーサリアムはビットコインがデジタル資産を発行したり、スマートコントラクトを書くことができない問題を解決しました。Z コインはビットコインのプライバシーの問題を解決しました。

長期的な視点で見ると、ビットコイン、ETH、Z コインは今が買い時であり、すでに底から何倍も上昇しています。ある人々はダークホースを探し、百倍あるいは千倍の利益を得られるコインを見つけたいと思っています。私の見解は、それは存在しますが、見つけるのは非常に難しいということです。それは以下の特徴を満たすべきです:

機能的な革新があり、何らかの問題を解決するか、未来の新しい方法を導くものである;

その発明者やチームが注目されないこと、なぜならそうでないと初期価格が非常に低くなるからです;

もしあなたがそれを見つけたら、ぜひ私にも知らせてください:)

最後に、すべてのデジタル通貨の投資は、自分のローカルウォレットに保存し、完全な安全バックアップを行うべきです。

ブロックチェーンの企業向けアプリケーションについて言うと、皆が最初に思い浮かべるのは、IBM が主導する hyperledger fabric プロジェクトと、Microsoft、Intel、Morgan などの大企業が参加する企業イーサリアム(Enterprise Ethererum)プロジェクトです。

企業イーサリアム連合が設立されたばかりで、その製品の発表にはまだ時間がかかります。hyperledger fabric 1.0 alpha はすでに発表されています。私は国内で最初の一部の hyperledger を使用して企業向けブロックチェーンの設計と開発に参加する機会がありました。不幸なことに、私はそれが良くないと感じています。非常に良くないです。私たちは間違った道を歩んでいるようで、fabric の設計者も間違った道を歩んでいるようです。

問題 1:アプリケーションシステムとブロックチェーンシステムを区別しない

fabric の設計はアプリケーションシステムとブロックチェーンシステムを区別していません。fabric は皆をアプリケーションシステムをブロックチェーン化するように導こうとし、元々簡単に解決できる問題を複雑化しています。例えば、サプライチェーンシステムはアプリケーションシステムと呼ばれ、すでに存在しており、ブロックチェーン技術が適用される前に大規模に存在していました。私たちは今それを改造するか、再設計してブロックチェーンの特性を持たせようとしています。fabric が提供するソリューションは、私たちが大部分のビジネスロジックを chaincode に入れるように導き、システム全体をブロックチェーンシステムに変えてしまいます。これは非常に間違っています。その理由は 3 つあります:

ブロックチェーンの運用効率は非常に低い;

ブロックチェーンのストレージ消費が高く、クエリの効果が非常に悪い(fabric 1.0 は構造化クエリをサポートしていますが、例えば CouchDB のように、従来の mysql と比較してその効率は 1 桁低いです);

システムが過度に複雑であり、必要がありません。

問題 2:endorsement の設計は似て非なるもの

fabric 1.0 の endorsement policy の設計は理論上は機能しますが、実際の運用では効果が非常に悪いです。例えば、サプライチェーンブロックチェーンシステムが 3 社を含む場合、私たちはそれぞれのデータセンター(またはクラウドシステム)に 1 つの peer(同時に endorse peer と commit peer)をデプロイします。私たちの policy は、必ずこの 3 つの peer の endorsement を同時に取得することと定義します。取引が発生すると、私たちのリクエストはネットワークを通じてパブリックネットワークを越えて各自のデータセンター(またはクラウドシステム)に入ります。そして各 peer と相互作用して endorsement を取得します。この間の遅延は非常に不確定で、大きくなる可能性があり、さまざまな取引の失敗を引き起こす可能性があります。

問題 3:channel の設計は愛憎入り混じる

fabric 1.0 の channel 設計は、異なる企業間の商業プライバシーを大いに保護できる素晴らしい機能のように見えます。しかし、それは不完全であり、また使用が難しいです。なぜなら、異なる channel 間で相互作用できず、多くのデータを複数の異なる channel 間で共有する必要があるため、冗長データを異なる channel に書き込むか、システムを非常に細かい粒度に設計して、異なる peer が複数の channel に参加するようにする必要があります。どちらの方法も、簡単な問題を複雑化しています。システムをより複雑にし、エラーが発生しやすくなります。

問題 4:docker を使用して chaincode を実行する設計が粗雑

イーサリアムのように EVM を設計しているわけではなく、単に docker を使用して chaincode を実行するため、その設計は非常に粗雑であり、運用中に多くの問題が発生します。この点は非常に理解しやすく、多くを語る必要はありません。

以上は fabric 設計の問題についてですが、enteth を使用すれば問題がないのでしょうか?明らかに、私はイーサリアムを好みます。企業向けイーサリアム(enteth)は、上記の問題を大いに解決するでしょう。しかし、すべてを解決するわけではなく、解決できない核心的な問題があります:なぜ私たちはブロックチェーンを使用するのか?

ブロックチェーンの唯一の役割は、信頼の問題を解決することです。改ざん防止、無抵抗、公開透明(これは企業アプリケーションには必ずしも適用されない)な取引と商業環境を提供します。

私たちのサプライチェーンの例では、3 社 A、B、C が関与しています。fabric のソリューションでも enteth のソリューションでも、ABC 間のデータの一貫性を保証することしかできません。しかし、A がデータを改ざんした場合、BC はすべてのデータのコピーを持っているため、A の改ざん行為を簡単に証明できます。この時、A はハッカーを雇い、BC システムに侵入し、BC システム内のデータコピーも改ざんしました。BC システムに侵入する難易度は、パブリックチェーン(例えばイーサリアム)で 51% の計算能力をハイジャックする難易度よりもはるかに低いです。

実際、現実の商業環境では、多くのシステムが強い側(例えば A)によって提供され、BC にそのブロックチェーンシステムを展開するのを助けています。このような環境では、ブロックチェーンの改ざん防止特性が効果を発揮しにくいです。

さらに、fabric や enteth に基づくブロックチェーンソリューションは、展開と運用時にも多くの問題があります。一般的に、複数の企業が共同でブロックチェーンシステムを開発することは非常に難しく、通常はそのうちの 1 社または特定の第三者ソフトウェア会社が提供します。関連企業は相応の知識が不足しているため、ソフトウェア提供者によってバックドアを残されることが容易であり、これによりブロックチェーンの改ざん防止特性が安全に保証されません。

以上の問題を考慮し、筆者は、共有チェーン(例えばイーサリアム)に基づく企業向けアプリケーションソリューションが未来の一つの方向性になると考えています(少なくとも必要な補完です)!

設計思考:

企業向けブロックチェーンアプリケーションで必要なブロックチェーンの部分を抽出し、論理的にアプリケーションシステムとブロックチェーンシステムに分け、公共チェーン(例えばイーサリアム)を使用してそのブロックチェーン機能を実現します。

このように設計する利点は多くあります。例えば:

アプリケーションシステムとブロックチェーンシステムを分離し、既存システムの機能と特性を最大限に再利用する;

公共ブロックチェーンのネットワークの安全性、改ざん防止などの特性を利用してブロックチェーン機能を保証する;

設計がシンプルで、コストが非常に低い;

公共チェーンが企業の問題を解決することは、多くの課題にも直面します。主な課題は以下の通りです:

課題 1:企業向けアプリケーションのプライバシー問題

企業向けアプリケーションは商業、ユーザーデータを含み、システムは大量の秘密保持と安全対策を必要とし、ネットワーク上に公開されて漏洩することはできません。この問題を解決するための 2 つの選択肢があります:

暗号化し、暗号化データのみを公共ネットワークに保存する;

二重分離し、ヘッダー情報とデータのハッシュ値のみを公共ネットワークに保存し、実データは安全な企業環境に保存する。

課題 2:公共チェーンネットワークのコストの問題

公共ネットワーク(例えばイーサリアム)を使用して企業のブロックチェーンを保存する場合、高いネットワークコストに直面します。特に大量のストレージが関与する場合です。この問題を解決するための 2 つの選択肢があります:

企業ブロックチェーンのヘッダー情報のみを保存する(ビットコインの SPV に似ている)、ブロック内容は非常に安価な企業データ環境に置く;

機能を剪定し、歴史的に無用なデータをバックアップ保存し、剪定する。

以下に筆者が提案する 2 つのソリューションを示します:

ソリューション 1:イーサリアムに基づく企業アプリケーションソリューション

イーサリアムのスマートコントラクト内で企業ブロックチェーンのヘッダー情報を維持する; -〉ネットワークの安全性、改ざん防止

企業ブロックチェーンのブロック内容を二次ストレージ(安全な企業ストレージ環境)に置く; -〉企業情報のプライバシー保護、コスト削減

歴史的ヘッダー情報を剪定する; -〉コスト削減

イーサリアムアドレスと企業のアイデンティティを関連付ける; -〉無抵抗

ソリューション 2:バイトボール(byteball)に基づく企業アプリケーションソリューション

バイトボールのストレージ機能を使用して企業ブロックチェーンを形成する; -〉ネットワークの安全性、改ざん防止;

敏感な情報を暗号化して保存し、安全レベルの高いものは二次ストレージに置く; -〉プライバシー保護;

ボールアドレスと企業のアイデンティティを関連付ける; -〉無抵抗

ボールのコストは比較的低く、ストレージスペースが大きく、将来的にはイーサリアムソリューションの良い補完となるでしょう。また、イーサリアムソリューションと組み合わせて使用することもできます;

上記のソリューションは、筆者の経験と知識に基づくまとめと考察です。私はすでに大多数の人々の前に立っていると信じています。また、興味のある企業があれば、ぜひ連絡して、上記のソリューションを実現するための実践的な探求を試みてください!

読み込み中...
文章は、創作者によって署名され、ブロックチェーンに安全に保存されています。