​MLSNEWS

——————◆ 20190704 ◆——————

• 介绍Heiswap - 以太坊混合器（Live on Ropsten！）

  Heiswap是一个以太坊混合器，允许用户以保密方式“清洗”他们的ETH（即发送者汇款给谁隐藏）。此时（2019年7月3日），Heiswap只能掩盖发件人与其相应收件人之间的联系，并要求参与者以固定面额发送ETH。

  这是因为，如果用户A在同一时间段内存入一个特殊的ETH特定数字，比如1.3256，而用户B提取的金额与此类似（例如，由于费用原因，1.325），那么将用户A链接到用户B就非常容易。

  要“清洗”他们的以太坊，用户只需将固定数量的以太坊存入Heiswap智能合约，等待池中有更多参与者，然后从智能合约中提取。

  Heiswap (黑 swap) is an Ethereum mixer that allows users to ‘wash’ their ETH in a confidential manner (i.e. who the sender sends money to is hidden). At this point in time (3rd July 2019), Heiswap is only able to mask the link between senders and their corresponding recipients, and requires participants to send ETH in fixed denominations.

  This is because if user A deposits some oddly specific number of ETH, say 1.3256, and user B withdraws an amount similar to that (e.g. 1.325, due to fees) around the same time frame, then it is very easy to link user A to user B.

  To “wash” their Ethereum, a user simply deposits a fixed amount of Ethereum into the heiswap smart contract, wait until there are more participants in the pool and then withdraws it from the smart contract.

• ＃15443添加getdescriptorinfo功能测试（测试）

  输出脚本描述符是用于描述scriptPubKeys的各个scriptPubKeys或HD链的语言。请参阅比特币核心文档。

  PR 15368 向描述符添加了校验和。由于描述符包含私钥或公钥，其中转录错误可能导致资金损失，因此必须使用校验和来确保正确的转录才是明智的预防措施。

  那些校验和基于与bech32地址格式类似的BCH编码方案。实现中有非常详细的注释 ，解释了如何计算校验和。

  PR还添加了一个新的RPC方法getdescriptorinfo，可以使用描述符调用该方法来分析描述符并添加校验和。那个RPC方法：

  • 是一个纯粹的功能。它没有副作用。

  • 不需要访问任何区块链或mempool数据

  • 无法访问钱包。

  PR还添加了单元测试 并更新了几个功能测试以使用校验和。一个Python实现 还添加校验和。

  PR＃15443专门为新的getdescriptorinfoRPC方法添加了功能测试。

  Output script descriptor are a language for describing individual scriptPubKeys or HD chains of scriptPubKeys. See the Bitcoin Core documentation.

  PR 15368 added checksums to descriptors. Since descriptors contain private or public keys where a transcription error can lead to loss of funds, having to checksum to ensure correct transcription is a sensible precaution.

  Those checksums are based on a similar BCH encoding scheme as the bech32 address format. There are very detailed comments in the implementation explaining how the checksum is calculated.

  The PR also added a new RPC method getdescriptorinfo that can be called with a descriptor to analyse the descriptor and add the checksum. That RPC method:

  • is a pure function. It has no side effects.

  • doesn’t need access to any blockchain or mempool data

  • doesn’t have access to the wallet.

  The PR also added unit tests and updated several functional tests to use the checksums. A python implementation of the checksum was also added.

  PR #15443 adds functional tests specifically for the new getdescriptorinfo RPC method.

• BLAKE2bF压缩函数预编译·问题＃152·以太坊/ EIPs

  对此类EIP的最常见关注是在协议级别添加特定功能是对以太坊“无特征”设计的侵犯。确实，该问题的更优雅的解决方案是简单地改进网络的可扩展性特征，以便使计算功能需要数百万气体用于日常使用。然而，与此同时，我认为某些操作值得通过预编译合同进行补贴，并且有一个重要的先例，最明显的是包含SHA256预编译合同，其主要包括允许与比特币区块链互操作。

  此外，BLAKE2b是预编译的理想选择，因为它具有极高的不对称效率。BLAKE2b针对现代64位CPU进行了大量优化，特别是利用24位和63位旋转来实现SIMD指令和小端算法的并行性。这些特性为本机CPU提供了出色的速度：每字节3.08个周期，或英特尔i5每秒1吉比特。

  相比之下，EVM的大端32字节语义不利于BLAKE2的有效实现，因此与计算EVM上的散列相关联的气体成本与本地计算该函数的真实成本不成比例。

  仅实施核心F压缩功能可以实现极大的灵活性和可扩展性，同时将协议级别的更改保持在最低限度。这将允许诸如树散列，增量散列，键控，盐渍和个性化散列以及可变长度摘要之类的功能，EVM上当前都不提供这些功能。

  破坏与此EIP的向后兼容性的风险很小，唯一的问题是如果有人在依赖地址0x000….0000d为空时建立合同。这种可能性很低，并且如果出现特定情况，则可以选择地址为任意值，可忽略不计的碰撞风险。

  The most frequent concern with EIPs of this type is that the addition of specific functions at the protocol level is an infringement on Ethereum’s “featureless” design. It is true that a more elegant solution to the issue is to simply improve the scalability characteristics of the network so as to make calculating functions requiring millions of gas practical for everyday use. In the meantime, however, I believe that certain operations are worth subsidising via precompiled contracts and there is significant precedent for this, most notably the inclusion of the SHA256 prcompiled contract, which is included largely to allow inter-operation with the Bitcoin blockchain.

  Additionally, BLAKE2b is an excellent candidate for precompilation because of the extremely asymetric efficiency which it exhibits. BLAKE2b is heavily optimized for modern 64-bit CPUs, specifically utilizing 24 and 63-bit rotations to allow parallelism through SIMD instructions and little-endian arithmetic. These characteristics provide exceptional speed on native CPUs: 3.08 cycles per byte, or 1 gibibyte per second on an Intel i5.

  In contrast, the big-endian 32 byte semantics of the EVM are not conducive to efficient implementation of BLAKE2, and thus the gas cost associated with computing the hash on the EVM is disproportionate to the true cost of computing the function natively.

  Implementation of only the core F compression function allows substantial flexibility and extensibility while keeping changes at the protocol level to a minimum. This will allow functions like tree hashing, incremental hashing, and keyed, salted, and personalized hashing as well as variable length digests, none of which are currently available on the EVM.

  There is very little risk of breaking backwards-compatibility with this EIP, the sole issue being if someone were to build a contract relying on the address at 0x000….0000d being empty. Te likelihood of this is low, and should specific instances arise, the address could be chosen to be any arbitrary value, with negligible risk of collision.