このブログとAlainによって投稿されたコメントにはそれを行うためのPythonコードがいくつかあります:

http://www.ocamlpro.com/2018/11/21/an-introduction-to-tezos-rpcs-signing-operations/

There are some Python code to do that in this blog and a comment posted by Alain:

http://www.ocamlpro.com/2018/11/21/an-introduction-to-tezos-rpcs-signing-operations/

1)ed25519公開鍵とそのバイト数について:

[1] から:

Ed25519キーは、32バイト(256ビット)の均一にランダムなバイナリシード(たとえば、ランダム入力でのSHA256の出力)として動作を開始します.次に、シードはSHA512を使用してハッシュされます.これにより64バイト(512ビット)が取得され、「左半分」(最初の32バイト)と「右半分」に分割されます.左半分は、いくつかの上位/下位ビットを設定およびクリアすることにより、curve25519プライベートスカラー「a」にマッサージされます.pubkeyは、この秘密のスカラーに「B」(ジェネレーター)を掛けることによって生成されます.これにより、32バイト/256ビットのグループ要素「A」が生成されます.

この文字列形式に変換するには、Base64形式の変換に従って6ビット文字に分割する必要があります.

このQ/A( [2] を参照)に基づくと、公開32バイト/256ビットキーは51バイトまたはBase64形式の68文字である必要があります.

あなたの重要な例には54文字があるようですが、上記のいずれでもないため、奇妙に思えます.

(5 x 10 + 1 x 4のスロットに変更しました)

edpktieBMr R9Df3dqzZA JpDZBXb1h1 88fyrQyRJcm5RH2WpbvM VR8b

これは、Tezosのエンコーディングが異なることを示しています:Base58.それはあなたの元のリンクで言及されていました:

コントラクト、アドレス、キー、および署名は、文字列、通常のBase58エンコードバージョン(読み取り可能)、または生のバイト(最適化)として書き込まれます.

デコードするために、FLFOCPの回答リンクコンテンツにPython呼び出しbase58check.b58decodeがありました.

2)署名とkey_hash

署名もbase58です. (1を参照)

key_hashについて、Tezos(数少ないデータ型の1つ)で独自のデータ型であり、次のように使用されていることがわかりました:

これらのアトミック型を組み合わせて、コンストラクターを使用してより複雑な型を構築できます.たとえば、pairint stringは、整数と文字列の2つの値のペアを表します.または、signature stringは、署名または文字列のいずれかである値を表し、タイムスタンプのリスト、タイムスタンプのリスト、およびマップkey_hashnatは、公開鍵のハッシュと正の整数の間の連想マップのタイプです.

その他のタイプ:

タイムスタンプ:現実世界の日付.

mutez:トークンを操作するための特定のタイプ.

Contract'param:コードのタイプを含むコントラクト.

アドレス:入力されていない契約アドレス.

操作:契約によって発行される内部操作.

キー:公開暗号化キー.

key_hash:公開暗号鍵のハッシュ.

署名:暗号署名.

3)キーハッシュ形成について:

私はそれの使用法とそれがTezosのネイティブタイプであるという事実以上のものを見つけませんでした.

私の情報源:

[1] https://blog.mozilla.org/warner/2011/11/29/ed25519-keys/

[2] https://crypto.stackexchange.com/questions/44584/ed25519-ssh-public-key-is-always-80-characters-long

[3] https://hackernoon.com/hash-consing-in-tezos-e4a59eeea5cd

1) About the ed25519 public key, and how it is in bytes:

From [1]:

Ed25519 keys start life as a 32-byte (256-bit) uniformly random binary seed (e.g. the output of SHA256 on some random input). The seed is then hashed using SHA512, which gets you 64 bytes (512 bits), which is then split into a “left half” (the first 32 bytes) and a “right half”. The left half is massaged into a curve25519 private scalar “a” by setting and clearing a few high/low-order bits. The pubkey is generated by multiplying this secret scalar by “B” (the generator), which yields a 32-byte/256-bit group element “A”.

To convert it to this String format you need to split it to 6 bit chars as per the Base64 format transformation.

Based on this Q/A (see: [2]), the public 32 bytes / 256 bit key should be 51 bytes or in Base64 format 68 characters.

Your key example seems to have 54 chars, which seems weird, because it is none of the above.

(I modified it to slots of 5 x 10 + 1 x 4)

edpktieBMr R9Df3dqzZA JpDZBXb1h1 88fyrQyRJc m5RH2WpbvM VR8b

That reveals Tezos have different encoding: Base58. That was mentioned in your original link:

contracts, addresses, keys and signatures are written as strings, in their usual Base58 encoded versions (readable), or as their raw bytes (optimized).

To decode, there was a python call base58check.b58decode in the FLF OCP's answer link content.

2) signature and key_hash

signatures are also base58. (see 1)

I found about key_hash that it is its own datatype in Tezos (one of the few ones) and it is used like this:

We can combine those atomic types to build more complex types using constructors. For instance pair int string represents a pair of two value, an integer, and a string, or signature string represents a value that is either a signature or a string, list timestamp a list of time-stamps, and map key_hash nat is the type of an associative map between the hash of a public key and a positive integer.

Other types:

timestamp: Dates in the real world.

mutez: A specific type for manipulating tokens.

contract 'param: A contract, with the type of its code.

address: An untyped contract address.

operation: An internal operation emitted by a contract.

key: A public cryptography key.

key_hash: The hash of a public cryptography key.

signature: A cryptographic signature.

3) About key hash formation:

I did not found more than the usage of it and the fact it is a native type in Tezos.

My Sources:

[1] https://blog.mozilla.org/warner/2011/11/29/ed25519-keys/

[2] https://crypto.stackexchange.com/questions/44584/ed25519-ssh-public-key-is-always-80-characters-long

[3] https://hackernoon.com/hash-consing-in-tezos-e4a59eeea5cd

Michelsonでは、これらのタイプは、最適化された読み取り可能な2つの異なる形式のデータを受け入れます(おっしゃるように).読み取り可能なバージョンは、base58-checkでエンコードされた文字列(edpk *、tz1 *、edsig *、KT1 *など)です.

最適化されたバージョンは、データのタイプに基づいて特定の形式に準拠する16進バイトです.たとえば、公開鍵は33バイトまたは34バイトのいずれかです.1バイトのタグの後に公開鍵バイトが続きます(ed25519キーの場合は32、33 secp256k1およびp-256曲線の場合).次のJavaScriptを使用してedpkをデコードできます:

 eztz.utility.buf2hex(eztz.utility.b58cdecode("edpktieBMrR9Df3dqzZAJpDZBXb1h188fyrQyRJcm5RH2WpbvMVR8b", eztz.prefix.edpk));
 

これはed25519キーであるため、0バイトのタグを付加して、最適化された形式で次のようにします.

 000a0813d070315836bab6e6f57244a291ba61832280fc3db7ad6d6f75920581b4
 

プレフィックスの詳細については、こちらおよび最適化されたフォームのさまざまな形式ここ

ハッシュ関数に関しては、32/33バイトの公開鍵の20バイトのハッシュを生成します.これがeztz ここでどのように行われるかを確認できます.

In Michelson, those types accept two different formats of data (as you mention) - optimized and readable. The readable versions are the base58-check encoded strings (edpk*, tz1*, edsig*, KT1* etc).

The optimized versions are hex bytes that conform to a specific format based on the type of data, for example public keys are either 33 or 34 bytes - a 1 byte tag followed by the public key bytes (32 for ed25519 keys, 33 for secp256k1 and p-256 curves). You can decode a edpk using the following javascript:

eztz.utility.buf2hex(eztz.utility.b58cdecode("edpktieBMrR9Df3dqzZAJpDZBXb1h188fyrQyRJcm5RH2WpbvMVR8b", eztz.prefix.edpk));

Since this is an ed25519 key, you prepend a 0 byte tag, giving you the following in optimized form:

000a0813d070315836bab6e6f57244a291ba61832280fc3db7ad6d6f75920581b4

You can view more about the prefixes here and different formats for optimized forms here

Regarding the hashing function, we generate a 20 byte hash of the 32/33 byte public key. You can see how this is done with eztz here