此博客中有一些Python代码可以做到这一点,而Alain发表了评论:

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个字节)和"右半部分".通过设置和清除一些高/低位,将左半部分按摩成曲线25519私有标量" a".通过将该秘密标量乘以" B"(生成器)来生成公钥,从而产生32字节/256位的组元素" A".

要将其转换为String格式,您需要按照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编码版本(可读)或原始字节(已优化)的形式写入.

要解码,FLF OCP的答案链接内容中有一个python调用base58check.b58decode.

2)签名和key_hash

签名也是base58. (请参阅1)

我发现有关key_hash的信息是Tezos中的数据类型(为少数几种之一),它的用法如下:

我们可以使用构造函数将这些原子类型组合起来以构建更复杂的类型.例如,对int字符串表示两个值对(整数和字符串)的对,或者签名字符串表示作为签名或字符串的值,列出时间戳,时间戳列表以及map key_hashnat是公钥的哈希值与正整数之间的关联映射的类型.

其他类型:

时间戳:真实世界中的日期.

mutez:一种用于处理令牌的特定类型.

contract'param:合同,其代码类型.

地址:无类型的合同地址.

operation:合同发出的内部操作.

key:公共加密密钥.

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-coning-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中,这些类型接受两种不同的数据格式(如您所述)-优化和可读.可读的版本是base58校验的编码字符串(edpk *,tz1 *,edsig *,KT1 *等).

优化版本为十六进制字节,根据数据类型符合特定格式,例如,公钥为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