どうも、管理部の大久保です。

先日公開した”Chaintopeエンジニアからの質問”は御覧いただけましたでしょうか。
見てないよ、って方はこちらからどうぞ。

一次面接までの壁／まず聞きたい！Chaintopeエンジニアからの質問

前記事のあまりのアクセス数の爆上がりに「炎上したらどうしよう…」と怯えてたら、
うちのエンジニアたちから
「chaintopeの立ち位置はっきりしていい」
と言われ、そういうものなのか、って思ったり。
気が弱い私です。（優しくされたい）

「学者、天才肌・・・それな」って感じする。

質問を公開した事に対して色々なレスポンス頂いたりしたんですけれども、
その中でも秀逸だなと思ったのは、

そんなの考えてるのはほんの一握りの学者や天才肌位だ

と言われた事。（勝手に引用したら怒られるかな、ごめんなさい。）
この方を批判したいのではないんです。
でも、この方の言う通り、その通りなんですよ！うちのエンジニアはそういう人ばっかりだなって。

エンジニアたちの会議とか参加すると、
学者みたいな人ばっかだし、あと「俺は天才」って公言してるやつもいるし（やや病的）。

ウチのエンジニアに同じ質問したら、社内で炎上しそうなほど回答が長かったよ

それで実際にChaintopeのエンジニアに同じ質問をしてみました。
全部だとあれなので一つだけ貼り付けます。

⑫現状のSmart Contractの抱える問題点は何か。また、それらの問題をどうやったら解決できるか？

（以下、原文まま）
Ethereum のメインネットで動作する Smart Contract を前提に書きます。まずは抱える問題をざっくり列挙しました。また、Smart Contract だけではなく、それを利用したアプリケーションである DApps についても含めています。

ビジネス視点での問題
1)DApps はサービスの提供者の主体がなくなるため、特定の事業者が収益を得るモデルが作りにくい。よって開発資金を得にくい。

開発者視点での問題
2)デプロイ後に仕様の拡張やバグの修正ができない。
3)攻撃ベクトルがないことを事前に証明することが困難。
4)利用できるリソースが少ないため、複雑な処理や多くのデータを扱うことができない。

利用者視点での問題
5)利用に際し手数料の負担が必要であり、Ethereumへのリテラシーを要求する。
6)DApps 自体は Decentorized に動作していても、開発体制は Centorized であることが多く、安心して使いにくい。

すべての解説と解決策を論じようとすると長くなるので、1つピックアップします。

> 4)利用できるリソースが少ないため、複雑な処理や多くのデータを扱うことができない。
Ethereum ではブロック単位に Gas Limit が設定されています。重たい処理も多くのガス代を支払えば実行できるのですが、このブロックの Gas Limit を超えるものは処理できません。

Ethereum にはゼロ知識証明の一種である zk-SNARK を使った匿名トランザクションと呼ばれるものが導入されましたが、大量のガスを消費しブロックのガスリミットを超えるため一時期はメインネットでは使えないと言われていました（徐々にブロックの Gas Limit は上昇しているため、今は使えるかと思いますが、、未確認です）

ストレージの利用によっても消費 Gas は増加するため、必要最低限のデータのみを記録し、他のデータは何らかの中央集権データベースに保管する必要があるため、DApps の構成上のデザインに制約を受けます。

このリソースの問題は、すべての Ehtereum フルノードがすべてのトランザクションを実行する必要があることに由来します。すべてのフルノードはすべてのトランザクションを実行しながらもほぼ15秒単位に生成されブロードキャストされるブロックを受け入れ続けなければいけませんので、1トランザクションに割り当てられるリソースに制約がつくのは仕方がないことのように思えます。

では、どうやって解決するかですが、基本的なアプローチとしては、フルノードがすべてのトランザクションを実行するのではなく、分担して実行し、結果だけを集めて1つの正しい状態（ワールドステート）を作るという方法になると思います。メインネットの構造を変えて実現するアプローチと、オフチェーン・サイドチェーンで実現するアプローチが考えられます。Ethereumはすでに動いているネットワークであるので、これをダイナミックに変えるよりも、この上のレイヤーとして積み上げていくほうが有望なように思います(まぁ、Plasma ですね)。これをいかに安全に、効率的に、トラストレスに実現するかという具体的な議論を積み上げていく必要があると考えています。
（以上、原文まま）

↑に対するChief Ethereum Researcherの感想

私の感想は「長いよ」しかなかったんですが、
これを見た、ウチの中城CERが突っ込みを入れてました。

（以下、原文まま）
とりあえず感想だけ。他意はないです。
回答内容がほかの質問と被りそう。
4)が問題であるのか？というのも考察の余地があり。
本来通りの「契約」的な意味を満たすのであれば、
外部から与えられたデータに対して反応すればよく、
スマートコントラクト事態は最低限のデータだけ持てばよいかと。

あと結論がplasmaになるのもちょっと面白くないかなｗ
未来の想定だからもう少しドラスティックな解答があるほうが楽しいです。

個人的には2), 3), 5)あたりに対しての回答があるとうれしい。
問題点は十分網羅できていて理解してるなっていうのは十分伝わりました。
（以上、原文まま）

こっちは短くていいですね。
如何でしょうか。
こんな感じで会話は進んでいくと思われます。
またなんかあれば、皆さまのTwitterとかで晒して頂ければ幸いです。

で、最後にやっぱり歓迎スキルは"C++"

前記事でも書いたんで、繰り返しになるんですが、質問は

Chaintopeと応募して下さる方が、お互いの考え方を知るためのもの

と位置付けてます。だから”質問”と言っても”正解”はないです。

どこの会社に所属しているとか、何の仕事してる、とか関係なく、
私はこれをやりたいんです、っていう話が聞きたい、ということですね。

でもさー、いきなり初対面それ言わないでしょ。
だから質問とかカッコつけて言っただけなの、っていうことでご了承ください。
気が弱い私です。（２回目）

今、社内で開発をしていくのに、一番困ってるのは、
安土CTOと一緒にBCの新サービス開発してくれる人が圧倒的に少ないことです。
どういう人に来てほしい？って聞くと、強く「C++出来る人」とのことでした。
これ100万回位言われてます。

どういう事やってるのかについて詳しく聞きたい人は
安土CTOのTwitterまでどうぞ（っていうと多分怒られるけどごめん）。

安土CTOに怒られてもめげない学者・天才をお待ちしております！