GOでのカスタムコード実行

これは、実際にはすべてスマートコントラクトに関するものです。

しかし、スマートコントラクトが何であるかをまったく想像しておらず、一般的に暗号化とは程遠い場合は、データベース内のストアドプロシージャとは何か、完全に想像できます。 ユーザーは、サーバー上で動作するコードを作成します。 ユーザーがそれらを作成して公開すると便利であり、それらを実行しても安全です。

残念ながら、セキュリティはまだ開発されていないため、ここでは説明しませんが、いくつかのヒントを示します。

また、Goについても記述しますが、そのランタイムにはいくつかの非常に具体的な制限がありますが、最も重要なのは、概して、外出中でない別のプロジェクトにリンクできないことです。これにより、サードパーティのコードを実行するたびにランタイムが停止します。 一般に、ある種のインタープリターを使用するオプションがあります。これに対して、完全に健全なLuaと完全に健全なWASMが見つかりましたが、何らかの理由でLuaにクライアントを追加したくありません。 、毎月更新されるため、仕様が確定するまで待機します。 2番目のエンジンとして使用します。

彼自身の良心との長い戦いの結果、GOでスマートコントラクトを作成することが決定されました。 実際、コンパイルされたGOコードを実行するためのアーキテクチャを構築する場合、セキュリティのためにこの実行を別のプロセスに転送する必要があり、別のプロセスに転送するとIPCのパフォーマンスが低下しますが、後で実行可能ファイルのボリュームを理解したときにコード、このソリューションを選んだのはなんとなく楽しいことでした。 問題は、個々のコールに遅延が追加されるものの、スケーラブルであることです。 多くのリモートランタイムを上げることができます。

それが明確になるようになされた決定についてもう少し。 各スマートコントラクトは2つの部分で構成され、1つの部分はクラスコードで、2番目の部分はオブジェクトデータです。したがって、同じコード上で、コードを公開したら、基本的に同じ動作をする多くのコントラクトを作成できますが、設定は異なります、および異なる状態で。 さらに話を進めると、これはすでにブロックチェーンについてであり、この話のトピックではありません。

そして、GOを実行します

プラグインメカニズムを使用することにしました。 彼は次のことを行い、プラグインとなるものを特別な方法で共有ライブラリにコンパイルし、それをロードしてシンボルを見つけ、そこで実行を渡します。 ただし、GOにはランタイムがあり、これはほぼ1メガバイトのコードであり、デフォルトではこのランタイムもこのライブラリに移動し、すべての場所にraznipipennyランタイムがあります。 しかし、今、私たちは将来、それを打ち負かすことができると確信して、それを選ぶことにしました。

ライブラリを構築するときはすべて簡単です。キー-buildmode = pluginでビルドし、.soファイルを取得して開きます。

p, err := plugin.Open(path) 

興味のあるキャラクターを探します：

 symbol, err := p.Lookup(Method) 

そして今、変数が関数であるか関数であるかに応じて、それを呼び出すか、変数として使用します。

このメカニズムの裏にはシンプルなdlopen（3）があり、ライブラリをロードしてプラグインであることを確認し、ラッパーを作成します。ラッパーを作成するとき、エクスポートされたすべての文字はインターフェイス{}にラップされて保存されます。 関数の場合は、正しいタイプの関数に減らして、変数の場合は単純に呼び出す必要があります-変​​数のように動作します。

覚えておくべき主なことは、シンボルが変数である場合、それはプロセス全体でグローバルであり、あなたはそれを考えずに使用できないことです。

プラグインで型が宣言されている場合、たとえば、プラグインの関数に引数として渡すなど、メインプロセスが処理できるように、この型を別のパッケージに入れるのが理にかなっています。 これはオプションであり、スチームや反射を使用することはできません。

コントラクトは対応する「クラス」のオブジェクトであり、最初はこのオブジェクトのインスタンスがエクスポートされた変数に格納されているため、別の同じ変数を作成できます。

 export, err := p.Lookup("EXPORT") obj := reflect.New(reflect.ValueOf(export).Elem().Type()).Interface() 

そして、すでに正しい型のこのローカル変数の内部で、オブジェクトの状態を逆シリアル化します。 オブジェクトが復元されたら、そのメソッドを呼び出すことができます。 その後、オブジェクトがシリアル化されてストアに再び追加されると、コントラクトのメソッドを呼び出しました。

方法に興味があるが、ドキュメントを読むのが面倒すぎる場合：

 method := reflect.ValueOf(obj).MethodByName(Method) res:= method.Call(in) 

途中で、正しい配列の引数を含む空のインターフェイスを配列に入力する必要があります。興味がある場合は、それがどのように行われたかを参照してください、ソースは開いていますが、 履歴でこの場所を見つけることは困難です。

一般的に、すべてが私たちのために働いた、あなたはクラスのようなものでコードを書き、ブロックチェーンにそれを置き、ブロックチェーン上にこのクラスのコントラクトを再び作成し、それに対してメソッド呼び出しを行い、コントラクトの新しい状態がブロックチェーンに書き戻されることができます いいね！ 手元のコードで新しい契約を作成する方法は？ 非常に簡単です。新しく作成されたオブジェクトを返すコンストラクタ関数があります。これは新しいコントラクトです。 これまでのところ、すべてはリフレクションによって機能し、ユーザーは次のように記述する必要があります。

 var EXPORT ContractType 

そのため、どのシンボルがコントラクトの表現であるかがわかり、実際にはそれがテンプレートとして使用されました。

あまり好きではありません。 そして、私たちは激しく叩きました。

解析

第一に、ユーザーは余計なものを書くべきではなく、第二に、コントラクトとコントラクトの相互作用はシンプルで、ブロックチェーンを上げることなくテストされるべきだという考えを持っています。ブロックチェーンは遅くて難しいです。

したがって、基本的には理解可能なソリューションであるコントラクトとラッパーテンプレートに基づいて生成されるラッパーでコントラクトをラップすることにしました。 まず、ラッパーはエクスポートオブジェクトを作成し、次に、ユーザーが契約を作成するときに契約が収集されるライブラリを置き換えます。基礎ライブラリは内部のmokaで使用され、契約が公開されると、ブロックチェーン自体で機能する戦闘に置き換えられます。

まず、コードを解析し、一般的に何を持っているかを理解し、BaseContractから継承された構造を見つけて、その周りのラッパーを生成する必要があります。

これは非常に簡単に行われます。[]バイトのコードでファイルを読み取りますが、パーサー自体はファイルを読み取ることができますが、すべてのAST要素が参照するテキストがどこかにあり、ファイル内のバイト番号を参照し、さらに受け取りたい構造コードはそのままで、次のようなものを取ります。

 func (pf *ParsedFile) codeOfNode(n ast.Node) string { return string(pf.code[n.Pos()-1 : n.End()-1]) } 

実際にファイルを解析し、最上位のASTノードを取得して、そこからファイルをクロールします。

 fileSet = token.NewFileSet() node, err := parser.ParseFile(fileSet, name, code, parser.ParseComments) 

次に、最上位ノードから始めてコードを調べて、興味深いものをすべて別の構造に収集します。

 for _, decl := range node.Decls { switch d := decl.(type) { case *ast.GenDecl: … case *ast.FuncDecl: … } } 

宣言、ファイルに定義されているすべてのリストである配列に既に解析されていますが、内部の内容を記述しないDeclインターフェースの配列であるため、各要素は特定の型に変換する必要があります。 go / astのインターフェースは、むしろ基本クラスです。

GenDeclおよびFuncDeclタイプのノードに興味があります。 GenDeclは変数または型の定義であり、内部の型が何であるかを正確に確認し、もう一度操作できるTypeDecl型にキャストする必要があります。 FuncDeclはより単純です。これは関数であり、Recvフィールドが入力されている場合、対応する構造のメソッドです。 テキスト/テン​​プレートを使用し、表現力があまりないため、これらすべてを便利なストレージに収集します。

個別に覚えておく必要があるのは、BaseContractから継承されたデータ型の名前だけであり、その周りで踊ります。

コード生成

そのため、コントラクトに含まれるすべての型と関数を知っており、着信メソッド名と引数のシリアル化された配列からオブジェクトに対してメソッド呼び出しを行うことができる必要があります。 しかし、結局のところ、コード生成の時点では、契約のデバイス全体がわかっているので、契約ファイルの隣に、同じパッケージ名を持つ別のファイルの隣に置き、そこに必要なすべてのインポートを入れます。タイプはすでにメインファイルで定義されており、不要です。

そして、ここが主なものであり、関数のラッパーです。 ラッパーの名前はある種のプレフィックスで補完され、ラッパーは簡単に見つけられるようになりました。

 symbol, err := p.Lookup("INSMETHOD_" + Method) wrapper, ok := symbol.(func(ph proxyctx.ProxyHelper, object []byte, data []byte) (object []byte, result []byte, err error)) 

各ラッパーには同じシグネチャがあるため、メインプログラムから呼び出す場合、余分なリフレクションは必要ありません。唯一のことは、関数ラッパーがメソッドラッパーと異なることであり、オブジェクトの状態を受け取ったり返したりしません。

ラッパーの中には何がありますか？

関数の引数に対応する空の変数の配列を作成し、インターフェイスの配列の型の変数に入れ、引数を逆シリアル化します。メソッドの場合は、オブジェクトの状態もシリアル化する必要があります。

 {{ range $method := .Methods }} func INSMETHOD_{{ $method.Name }}(ph proxyctx.ProxyHelper, object []byte, data []byte) ([]byte, []byte, error) { self := new({{ $.ContractType }}) err := ph.Deserialize(object, self) if err != nil { return nil, nil, err } {{ $method.ArgumentsZeroList }} err = ph.Deserialize(data, &args) if err != nil { return nil, nil, err } {{ if $method.Results }} {{ $method.Results }} := self.{{ $method.Name }}( {{ $method.Arguments }} ) {{ else }} self.{{ $method.Name }}( {{ $method.Arguments }} ) {{ end }} state := []byte{} err = ph.Serialize(self, &state) if err != nil { return nil, nil, err } {{ range $i := $method.ErrorInterfaceInRes }} ret{{ $i }} = ph.MakeErrorSerializable(ret{{ $i }}) {{ end }} ret := []byte{} err = ph.Serialize([]interface{} { {{ $method.Results }} }, &ret) return state, ret, err } {{ end }} 

注意深い読者は、プロキシヘルパーとは何かに興味がありますか？ -これはまだ必要な結​​合オブジェクトですが、現時点では、シリアル化と逆シリアル化の機能を使用しています。

さて、読んでいる人は誰でも「しかし、これらはあなたの議論です、どこから来たのですか？」と尋ねるでしょう。ここにも明確な答えがあります。はい、空からの十分なテキスト/テン​​プレートの星はありません。

method.ArgumentsZeroListには次のようなものが含まれます

 var arg0 int = 0 Var arg1 string = “” Var arg2 ackwardType = ackwardType{} Args := []interface{}{&arg0, &arg1, &arg2} 

また、引数には「arg0、arg1、arg2」が含まれます。

したがって、任意の署名を使用して、必要なものを呼び出すことができます。

しかし、答えをシリアル化することはできません。事実、シリアライザーはリフレクションで動作し、エクスポートされていない構造体のフィールドにアクセスできないため、エラーインターフェイスオブジェクトを取得し、そこから型の基礎のオブジェクトを作成する特別なプロキシヘルパーメソッドがあります。エラー。通常のエラーとは異なり、エクスポートされたフィールドにエラーテキストが含まれているため、多少の損失はありますが、シリアル化できます。

しかし、コード生成の滅菌器を使用する場合、それも必要ありません。同じパッケージでコンパイルされ、エクスポートされていないフィールドにアクセスできます。

しかし、契約から契約を呼び出したい場合はどうでしょうか？

契約から契約を呼び出すのが簡単だと思うと、問題の深さを理解できません。 事実は、コンセンサスによって別の契約の有効性を確認する必要があり、この呼び出しの事実はブロックチェーンで署名する必要があり、一般に、単に別の契約でコンパイルしてそのメソッドを呼び出すことは機能しませんが、本当にしたいのですが。 しかし、私たちはプログラマーの友人なので、すべてを直接行う機会を与え、システムの内部にすべてのトリックを隠す必要があります。 したがって、契約の開発は直接呼び出しのように実行され、契約は互いに透過的に引き合いますが、公開のために契約を収集する場合、別の契約の代わりにプロキシをスリップします。これは、契約に関するアドレスと呼び出し署名のみを知っています。

これをすべて整理する方法は？ -ジェネレーターがインポートされた各契約のプロキシを認識して作成できるように、特別なディレクトリに他の契約を保存する必要があります。

つまり、会った場合：

 import “ContractsDir/ContractAddress" 

インポートされた契約のリストに書き込みます。

ちなみに、このために契約のソースコードを知る必要はありません。既に収集した説明を知っている必要があるだけです。そのような説明をどこかに公開し、すべての呼び出しがメインシステムを通過する場合、別のコントラクトが言語で記述され、そのメソッドを呼び出すことができる場合、Goでそのスタブを記述できます。これは、直接呼び出すことができるコントラクトを持つパッケージのように見えます。 ナポレオンの計画、実装に取り​​掛かろう。

原則として、このシグネチャを持つプロキシヘルパーメソッドが既にあります。

 RouteCall(ref Address, method string, args []byte) ([]byte, error) 

このメソッドはコントラクトから直接呼び出すことができ、リモートコントラクトを呼び出し、解析してコントラクトに戻る必要があるシリアル化された応答を返します。

ただし、ユーザーはすべて次のように見える必要があります。

 ret := contractPackage.GetObject(Address).Method(arg1,arg2, …) 

まず、プロキシで、コントラクトメソッドのシグネチャで使用されるすべてのタイプをリストする必要がありますが、覚えているように、各ASTノードに対してそのテキスト表現を取得できます。そして、このメカニズムの時が来ました。

次に、あるタイプの契約を作成する必要があります。原則として、彼はすでにクラスを知っており、住所のみが必要です。

 type {{ .ContractType }} struct { Reference Address } 

次に、何らかの方法でGetObject関数を実装する必要があります。GetObject関数は、ブロックチェーン上のアドレスで、このコントラクトの操作方法を知っているプロキシインスタンスを返し、ユーザーにとってはコントラクトインスタンスのように見えます。

 func GetObject(ref Address) (r *{{ .ContractType }}) { return &{{ .ContractType }}{Reference: ref} } 

興味深いことに、ユーザーデバッグモードのGetObjectメソッドは直接BaseContract構造体メソッドですが、ここでは、SLAを観察して、便利なことを行うことを妨げるものは何もありません。 これで、制御するメソッドであるプロキシコントラクトを作成できます。 実際にメソッドを作成することは残っています。

 {{ range $method := .MethodsProxies }} func (r *{{ $.ContractType }}) {{ $method.Name }}( {{ $method.Arguments }} ) ( {{ $method.ResultsTypes }} ) { {{ $method.InitArgs }} var argsSerialized []byte err := proxyctx.Current.Serialize(args, &argsSerialized) if err != nil { panic(err) } res, err := proxyctx.Current.RouteCall(r.Reference, "{{ $method.Name }}", argsSerialized) if err != nil { panic(err) } {{ $method.ResultZeroList }} err = proxyctx.Current.Deserialize(res, &resList) if err != nil { panic(err) } return {{ $method.Results }} } {{ end }} 

ここで引数リストの構築と同じ話をします。私たちは怠け者でメソッドのast.Nodeを正確に保存しているため、計算にはテンプレートが知らない多くの型変換が必要なので、すべてが事前に準備されます。 関数を使用すると、すべてが非常に複雑になります。これは別の記事のトピックです。

私たちが持っている機能はオブジェクトコンストラクターであり、システムでオブジェクトが実際に作成される方法に多くの重点が置かれています。作成の事実はリモートエグゼキューターに登録され、オブジェクトは別のエグゼキューターに転送され、チェックされて実際にそこに保存され、そして無駄に多くの保存方法がありますこの知識の領域は暗号と呼ばれます。 そして、その考え方は基本的にシンプルで、アドレスのみが保存されるラッパーと、呼び出しをシリアル化し、残りを実行するシングルトンコンバインをプルするメソッドです。 送信されたプロキシヘルパーは使用できません。ユーザーから渡されなかったため、シングルトンにする必要がありました。

別のトリック-実際、私たちはまだ呼び出しコンテキストを使用しています。これは、誰が、いつ、なぜ、なぜ私たちのスマートコントラクトが呼び出されたかに関する情報を格納するオブジェクトであり、この情報に基づいて、ユーザーは実行を与えるかどうかを決定し、可能であればその後、どのように。

以前は、単にコンテキストを渡しました。これは、セッターとゲッターを持つBaseContract型の表現できないフィールドであり、セッターはフィールドの設定を1回のみ許可したため、コントラクトが実行される前にコンテキストが設定され、ユーザーはそれを読み取ることしかできませんでした。

しかし、ここに問題があります。ユーザーがこのコンテキストを読むのは、ある種のシステム関数（たとえば、別のコントラクトへのプロキシ呼び出し）を呼び出した場合だけです。このプロキシ呼び出しは誰にも渡されないため、コンテキストを受け取りません。 そして、ゴルーチンのローカルストレージが登場します。 独自に作成することはせず、github.com / tylerb / glsを使用することにしました。

現在のゴルーチンのコンテキストを設定および取得できます。 したがって、コントラクト内にゴルーチンが作成されていない場合、コントラクトを開始する前にコンテキストをglsに設定するだけで、メソッドではなく関数のみをユーザーに提供します。

 func GetContext() *core.LogicCallContext { return gls.Get("ctx").(*core.LogicCallContext) } 

そして彼はそれを喜んで使用していますが、たとえば、どの契約が現在誰かを呼び出しているかを理解するために、RouteCall（）で使用します。

原則として、ユーザーはゴルーチンを作成できますが、作成するとコンテキストが失われるため、たとえば、ユーザーがgoキーワードを使用する場合、このような呼び出しをラッパーでラップする必要があります。 goroutineとそのコンテキストを復元しますが、これは別の記事のトピックです。

すべて一緒に

私たちは基本的にGO言語ツールチェーンの仕組みが好きです。実際、それは、たとえばビルドを行うときに一緒に実行される、1つのことを行うさまざまなコマンドの集まりです。 同じことをすることにしました.1つのチームが契約ファイルを一時ディレクトリに配置し、2番目のチームがそのラッパーを配置して3回目の呼び出しを行い、インポートされた各契約のプロキシを作成し、4番目がすべてをコンパイルし、5番目がブロックチェーンに公開します。 そして、すべてを正しい順序で実行するコマンドが1つあります。

やあ、GOからGOを起動するためのツールチェーンとランタイムができました。 まだ多くの問題があります。たとえば、未使用のコードを何らかの方法でアンロードする必要がある、停止したプロセスがハングして再起動することを何らかの方法で判断する必要がありますが、これらは解決方法が明確なタスクです。

はい、もちろん、私たちが書いたコードはライブラリのふりをしていないので、直接使用することはできませんが、動作するコード生成の例を読むことは常に素晴らしいです。 したがって、コード生成の一部はコンパイラーで見ることができますが、 エグゼキューターでどのように開始するかです。