AIP #006 - To Support blake2b Hashing in Solidity VM

[rakeshgohel01]

---

Title: To Support blake2b Hashing in Solidity VM
Author(s): Rakesh Gohel
Type: Core
Status: REVIEW
Creation Date: October 2, 2018
Contact Information: [email protected]

Summary

Need for a method to calculate blake2b hash in Aion solidity.

Value Proposition

Aion kernel's internal hash function is blake2b and being so popular fast hash function should be accessible in the smart contract.

Motivation

The primary motivation for the proposol is to support blake2b hash in bridge operator contract proposed in AIP-005. The signatories or validators and the bridge operator currently use blake2b hash when they sign bundles. Thus, when given list of transfer transactions and source block hash, the smart contract needs to have access to generate the blake2b hash and perform signature verfication.

Non-Goals

The scope of this document is for supporting black2b hash function only for Aion kernel; the other hashing functions are not included.

Success Metrics

The key indicator of success for this function can be measured by number of contracts using them. The bidirectional bridge has bridge operator contract which consumes this functionality.

Description

The signatories or validators can use the Aion's ecosystem provided methods to sign and verify the bundles produced by bridge operator. The AION supports ED25519 curve with blake2b hash function.

The singatory already has access to blake2b hash function from Aion Ecosystem. When a bundle is signed and sent to bridge operator contract, the bridge operator contract validates publicly on blockchain that whoever claims to be signatory is genuine entity. To verify the hash on blockchain using smart contract requires solidity to support this function through a method. Currently, Aion solidity does not have a capability to perform blake2b hashing.

High-Level Architecture

N/A

Specification

Definitions

• Bridge Operator: An organization(s) / project (s) / account that execute the required functions to enable a cross-chain transaction on behalf of the token holder
• Bridge Contract: A smart contract designed to receive, verify and emit events and signature bundles from/to a specific bridge
• Signatory/validator : The entity which independently goes to the source chain to verify the bundle transfer initiated by bridge operator.

Method

A public function must be implemented.

blake2b function

Returns hash of the arguments (tightly coupled).

parameters
...: Arguments.
returns: bytes32.

    function blake2b(...) public returns (bytes32);

Logic

Tightly pack the arguments before initiating blake2b hash.

Cross Chain Functionality

No cross chain function's involved for this AIP.

Risks & Assumptions

Compatibility notes:
Blake2b hash is natively available in Aion chain, but may not be the case with different blockchains. Thus if Aion contract needs to be ported on any Ethereum compatible smart contract, the destination blockchain's hash function should be used.

Test Cases

N/A

Implementations

N/A

Dependencies

N/A

Copyright

All AIP’s are public domain. Copyright waiver: https://creativecommons.org/publicdomain/zero/1.0/

[sampajotphipps]

@mocha384 Could you change the Type to "Core".

[rakeshgohel01]

It's done. @sampajotphipps

[sampajotphipps]

@mocha384 updated status to in REVIEW

[sampajotphipps]

Open call for any final feedback, comments or suggestions.

[qoire]

@AionJayT this touches on some kernel changes

[AionJayT]

@mocha384 I think we can do it with the pre-compiled contract as a short-term solution.
this AIP requires not just VM but also compiler, client API change. It will take some resources to implement it.

[iamyulong]

Do we have an idea how to implement this. IMO this can be either through opcode or pre-compiled contract?

[qoire]

I believe a viable route is implementing this through precompileds. What's probably more interesting is whether we want to support encoding:

https://medium.com/@libertylocked/what-are-abi-encoding-functions-in-solidity-0-4-24-c1a90b5ddce8

I know by default specifying something like sha256("hi", "there") automatically infers some sort of encoding.

Associated implementation here:

https://github.com/ethereum/solidity/blob/a2f5087d13274d6832669a39694ee5a3bf68f878/libsolidity/codegen/ExpressionCompiler.cpp#L975-L1073

Although I cannot say without more context how extensive the changes are.

Or we can simply defer this ^ encoding feature until a later date... since IMO it doesn't imply breaking changes, we can simply implement blake2b(bytes) returns (bytes32) for now.

[AionJayT]

modified the method name to

    function blake2b256(...) public returns (bytes32);

[dhagell]

Hello, I've started migrating an implementation here https://github.com/dhagell/Project-Alchemy/blob/master/contracts/BLAKE2b/BLAKE2b_AION.sol (WIP)
forked from the Consensys. I'm just wondering if it would be useful considering your efforts.

[NoahMarconi]

Hello, I've started migrating an implementation here https://github.com/dhagell/Project-Alchemy/blob/master/contracts/BLAKE2b/BLAKE2b_AION.sol (WIP)
forked from the Consensys. I'm just wondering if it would be useful considering your efforts.

Awesome to see a solidity implementation as a stop gap solution. Ideally Aion would support this method using precompile.