ここでイーサリアム/ソリディティ開発者、いくつかのソリディティ契約をテゾスに移行しようとしています。いくつかの質問に光を当てることを望んでいました

質問4への回答:

再利用とモジュール性

再利用とモジュール性について説明します.継承は多くのメカニズムの1つです.

• Michelson には、呼び出しを除いて、コードを再利用するメカニズムがありません. 既存の「ライブラリ」直接契約します.
• 私が理解している限り、アーキタイプにはユーザーが拡張できるものは含まれていません コードの再利用のメカニズム.アクション(メソッドに類似)はできません 異なるステートマシン間で共有( 契約).さらに、アクションは相互に呼び出すことができないため、 作曲できません.ステートマシンを拡張したり、 作曲.アーキタイプコントラクトは1つのファイルで構成されています.しかしながら、 Archetypeには、一般的にカプセル化する一連の拡張機能が含まれています signedなどのパターンを使用しました. アクションは別の引数の署名である必要があります.
• LIGO コントラクトは、使用される構文に関係なく、次のもので構成されます. 関数のセット.これらの機能は再利用でき、 任意の関数から期待されるように一般的に構成可能 再帰を除いて、言語.さらに、Ligoコンパイラ 入力コントラクトで Cプリプロセッサ(cpp)を呼び出します. 使用を通じてある程度の再利用と構成可能性を可能にします #includeディレクティブの.道徳的に、これは同等です 含まれているファイルをコピーして貼り付ける:保存するための名前空間はありません 名前の衝突から.最後に、cppの使用は文書化されておらず、 このメッセージで次のように証明されているように、変更される可能性があります tezos-devslackの#ligoチャネルのメッセージ:
>

現在、LIGOにはCプリプロセッサcppが付属しています. 貧乏人のモジュールシステムアラC.私たちがすべき理由はいくつかあります. すぐにそして長期的にそれを取り除く[...]

• 最後に、 SmartPy コントラクトは、実際にはPythonプログラムです. SmartPyライブラリを使用して契約を作成し、アクセスできる メタプログラミングレベルのすべてのPython機能に( つまり、コントラクトを生成するコード).あれは、 モジュール、クラス(継承あり)、関数、高レベル 関数、デコレータ、および構成.

契約間のコミュニケーション

• Michelson には、相互契約を簡素化するための特定のメカニズムはありません. コミュニケーション.他の契約への呼び出しは、を介して手動で作成する必要があります TRANSFER_TOKENS 命令.コールバックは(再び)エンコードする必要があります 継続渡しスタイル(CPS)を手動で使用する).
• LIGO についても同じことが言えます. および SmartPy .
• 現在のバージョンでは、アーキタイプは契約間の通信をほとんどサポートしていません.なので 私が見る限り、 transfer 命令. の引数やエントリポイントを指定することはできません 呼び出されたコントラクト(おそらく、タイプunitのコントラクトのみが サポートされているターゲット). CPSスタイルをコーディングするための特定のヘルパーはありません.ただし、これはArchetypeの将来のバージョンで修正され、以下のBenoitの回答で示されています.

In response to question 4:

Reuse and modularity

We discuss reuse and modularity, of which inheritance is one of many mechanisms:

• Michelson has no mechanism for code reuse, except for calling existing "library" contracts directly.
• As far as I understand, Archetype includes no user-extendable mechanisms for code reuse. Actions (akin to methods) cannot be shared between different state machines (akin to contracts). Furthermore, actions cannot not call each other, so cannot be composed. State machines cannot be extended or composed. Archetypes contracts are composed of one file. However, Archetype contains a set of extensions, that encapsulate commonly used patterns such as signed, which requires that one argument of an action should be the signature of another argument.
• LIGO contracts, irrespective of the syntax used, are composed of a set of functions. These functions can be reused, and are in general composable as one would expect from functions in any language, with exception of recursion. What's more, the Ligo compiler calls the C preprocessor (cpp) on input contracts, which enables a certain degree of reuse and composability through the use of #include directives. Morally, this is equivalent to copy-pasting the included file: there is no namespacing to save you from name clashes. Finally, the use of cpp is undocumented and subject to change, as testified to by this message by the following message on the #ligo channel on the tezos-dev slack:

Currently, LIGO is shipped with the C preprocessor cpp which acts as a poor man's module system a la C. There several reasons why we should get rid of it, both immediately and in the long term [...]

• Finally, SmartPy contracts, which are actually Python programs that use the SmartPy library to construct a contract, have access to all the Python features on the meta-programming level (in other words, the code that generates the contract). That is, modules, classes (with inheritance), functions, high-level functions, decorators and compositions.

Inter-contract communication

• Michelson has no specific mechanisms to simplify inter-contract communication. Calls to other contracts must be crafted manually through the TRANSFER_TOKENS instruction. Callbacks must be encoded (again) manually using continuation-passing style (CPS).
• The same holds for LIGO and SmartPy.
• In the current version, Archetype has little support for inter-contract communication. As far a I can see, there is only the transfer instruction, with which it is not possible to specify the argument nor the entry-point of the called contract (presumably, only contracts of type unit are supported targets). No specific helpers for coding CPS style. However, this is amended in future versions of Archetype, as indicated by Benoit's answer below.

アーキタイプに関するArvidの回答を補足するものがあります:

再利用とモジュール性

確かにArchetypeの拡張機能は、契約に機能を追加するための再利用可能なコードです.たとえば、ロールで「transferable 」拡張子を使用すると、契約に役割を別のアドレスに転送するために必要なアクション(つまり、エントリポイント).

たとえば、管理者の役割で「転送可能な」拡張機能を呼び出す:

 variable admin[%transferable%] role := @tz1iawHeddgggn6P5r5jtq2wDRqcJVksGVSa
 

は、2つのエントリポイントassign_new_adminとconfirm_new_adminを生成します.

設計の観点から、読みやすく信頼を維持するために、可能な限り単一のソースファイルに契約を保持するように努めました. たとえば、イーサリアムのコントラクトのほとんどは、通常、継承メカニズムによって文字通り数十のソースファイルに粉砕されており、スマートコントラクトの外観とは逆であると考えました.

拡張機能は現在のバージョン(0.1.12)ではまだ利用できませんが、間もなく利用できるようになります(いくつかのプルリクエストがあります...).

契約間のコミュニケーション

Archetypeではコントラクトコールがサポートされています.たとえば、次のArchetypeコントラクトは、アドレスKT1RNB9PXsnp7KMkiMrWNMRzPjuefSWojBAm

 archetype contract_caller

contract contract_called_sig {
   action set_value (n : int)
   action add_value (a : int, b : int)
}
variable c : contract_called_sig = @KT1RNB9PXsnp7KMkiMrWNMRzPjuefSWojBAm


action update_value(n : int) {
  effect {
    c.set_value(n)
  }
}

action add_one(n : int) {
  effect {
    c.add_value(n, 2)
  }
}
 

コントラクト署名にはcontractキーワードを指定する必要があり、コントラクトの呼び出しはオブジェクトのメソッドの呼び出しに似ていることがわかります.

この機能はdevブランチで利用可能であり、次のリリースで間もなく利用可能になります(通常、数週間で0.1.13).

Here is a complement to Arvid's answer regarding Archetype:

Reuse and modularity

Indeed Archetype's extensions are reusable codes to add features to a contract. For example, using the 'transferable' extension on a role adds to the contract the necessary actions (ie entry points) to transfer the role to another address.

For example, invoking the 'transferable' extension on an admin role:

variable admin[%transferable%] role := @tz1iawHeddgggn6P5r5jtq2wDRqcJVksGVSa

will generate the two entry points assign_new_admin and confirm_new_admin.

From a design perspective, we have tried to keep the contract in a single source file as much as possible, for ease of reading and trust-carrying purposes. Most of Ethereum's contracts, for example, are usually shattered in literally dozens of source files by inheritance mechanisms, and we thought it was the opposite as what a smart contract should look like.

Extensions are not available yet in the current version (0.1.12) but will be soon (they are a few pull requests away ...).

Inter contract communication

There is support for contract calling in Archetype. For example, the following Archetype contract calls a contract at address KT1RNB9PXsnp7KMkiMrWNMRzPjuefSWojBAm

archetype contract_caller

contract contract_called_sig {
   action set_value (n : int)
   action add_value (a : int, b : int)
}
variable c : contract_called_sig = @KT1RNB9PXsnp7KMkiMrWNMRzPjuefSWojBAm


action update_value(n : int) {
  effect {
    c.set_value(n)
  }
}

action add_one(n : int) {
  effect {
    c.add_value(n, 2)
  }
}

We see that the contract signature must be provided with the contract keyword and that the call to the contract is similar to invoking a method on an object.

This feature is available in the dev branch and will be available soon in the next release (0.1.13 typically in a couple of weeks).

Archetype/Ligoは、Michelsonが現在実行できるすべてのものを提供しますか、それともどちらかに制限がありますか?

LigoではなくMichelsonで何かが可能である場合、それはおそらく報告する価値のあるバグだと思います.Ligoの開発者は通常、この種の問題にすばやく答えます.

ただし、アーキタイプは意図的にチューリング完全ではなく、特にアーキタイプで無制限のループを実行することはできません(無制限のループはLOOPおよびLOOP_LEFTでサポートされています).

Do Archetype/Ligo provide everything that Michelson can currently do, or are there limitations with either?

I think if something is possible in Michelson and not in Ligo, it is probably a bug worth reporting, the Ligo devs usually quickly answer these kinds of issues.

Archetype however is purposely not Turing complete and in particular you cannot do unbounded loops in Archetype (unbounded loops are supported by the LOOP and LOOP_LEFT).

質問3に関して、@ezyの発言に続いて、SmartPyには、インラインMichelsonテンプレート(新しいバージョンの現在 https://SmartPy.io/dev ).

ここからアクセスできます: https://smartpy.io/dev/index.html?template=inlineMichelson.py .

 import smartpy_michelson as mi

...

    @sp.entry_point
    def concat(self, params):
        concat = mi.operator("CONCAT", [sp.TList(sp.TString)], [sp.TString])
        self.data.s = concat(["a", "b", "c"])

    @sp.entry_point
    def seq(self, params):
        self.data.value = abs(mi.seq([mi.ADD(), mi.MUL(), mi.DUP(), mi.MUL()], 15, 16, 17))
 

With respect to question 3, following @ezy remark, SmartPy has some inlining capabilities including with new opcodes as shown in the Inline Michelson template (of the new version, currently https://SmartPy.io/dev).

It's accessible here: https://smartpy.io/dev/index.html?template=inlineMichelson.py.

import smartpy_michelson as mi

...

    @sp.entry_point
    def concat(self, params):
        concat = mi.operator("CONCAT", [sp.TList(sp.TString)], [sp.TString])
        self.data.s = concat(["a", "b", "c"])

    @sp.entry_point
    def seq(self, params):
        self.data.value = abs(mi.seq([mi.ADD(), mi.MUL(), mi.DUP(), mi.MUL()], 15, 16, 17))