任意のタイプを受け入れる契約

必要に応じて、bytesとPACK/UNPACKを使用できます: http://tezos.gitlab.io/mainnet/whitedoc/michelson.html#operations-on-bytes

「任意のストレージ」の場合、キーの独自の規則(おそらくいくつかの文字列タグを含むパックされたペア/リスト/etc式)を使用して、pair (big_map bytes bytes) ...を使用できます..

これらのことを行うとき、型システムのいくつかの利点を放棄します.

現在、「タグ付き」データのサポートや規則はありません.bytesを「any」型として使用する場合、コンシューマー(UNPACK)は、予想されるMichelson型とその特定のセマンティクスを何らかの形ですでに知っている必要があります.バイトはMichelineのみをエンコードします.型なし(および注釈なし)の式.

If you must, you can use bytes and PACK/UNPACK: http://tezos.gitlab.io/mainnet/whitedoc/michelson.html#operations-on-bytes

For 'any storage', you can use pair (big_map bytes bytes) ..., with your own conventions for the keys (perhaps packed pair/list/etc expressions with some string tags).

When doing these things you abandon some benefits of the type system.

There is currently no support or convention for 'tagged' data. When using bytes as an 'any' type, the consumer (who will UNPACK) should somehow already know the expected Michelson type and its particular semantics: the bytes only encode a Micheline expression, with no type (and no annotations).

タイプがわかっている指定されたメソッドのセットにディスパッチするだけの場合、探しているのは«代替»タイプまたは合計タイプです.値は(Left(Right(...))です.)、つまり、メソッドの最終型へのLeftおよびRightコンストラクターのパス.

それ以外の場合は、完全に汎用バージョンが必要で、将来的に新しいメソッドと型を追加できるようにする場合は、UNPACKを使用して汎用Bytes型から引数を抽出できます.このように、すべてのメソッドはBytesメソッドであり、別の引数(たとえば、メソッドプロトタイプのハッシュ)を使用してディスパッチできます.これで問題は解決しますが、コントラクトの境界に静的制御がなくなることを意味します.コードにエラーが含まれている可能性があります.エラーはUNPACKが失敗した場合にのみ検出され、コントラクトが完全に役に立たなくなる可能性があります.

If you just want to dispatch to a specified set of methods, who ses types are known, what you are looking for is the « alternative » type or sum type, where the value is (Left (Right (... )), ie a path of Left and Right constructors to the final type of the method.

Otherwise, if you want a completely generic version, allowing addition of new methods and types in the future, you can use UNPACK to extract the argument from a generic Bytes type. This way, all the methods are Bytes method, and you can dispatch using another argument (a hash of the method prototype for example). Though it solves your problem, it means that there is no static control any more at the boundaries of your contract : your code might contain an error, that will only be detected when the UNPACK will fail, maybe making your contract completely useless.