📝
smartbch
  • Introduction
  • Whitepaper
  • FAQ
  • Mainnet
  • Testnets
  • Join Amber testnet as a Validator
  • Developer's Guide
    • Introduction
    • Deploy contracts using Truffle
    • Deploy contracts using Remix
    • JSON-RPC Endpoints
    • Staking Scheme
    • XHedge Smart Contract
    • Decision of the minimum gas price
  • Sha-Gate Bridge
    • Sha-Gate Specification
    • Sha-Gate Risk Analysis
    • Sha-Gate's Covenant
  • In-Depth Design Documents
    • Introduction
    • MoeingADS's General Ideas
    • MoeingADS's RabbitStore
    • MoeingADS's internal architecture
    • Benchmarking MoeingADS
    • Benchmarking MoeingEVM and MoeingADS
    • Benchmarking Testnet
    • Transaction Reordering in smartBCH
    • Transaction Parallel Execution in smartBCH
    • Send back-to-back Transactions
    • Data structures in world state
  • SmartBCH Evolution Proposals (SEPs)
    • SEP101: Store values with arbitrary length
    • SEP102: Adjustment of Used Gas
    • SEP109: On-chain Verification of Verifiable Random Functions
    • SEP18: Blockchain cheques on smartBCH
    • SEP20: Tokens on smartBCH
    • SEP206: Manipulate Native Token as a SEP20 Token
    • SEP201: Simple Stochastic Payment
  • Archives
    • Single Node Private Testnet
    • Multi-Node Testnet
    • Fake RPC Server for Testing
    • Test using MetaMask
Powered by GitBook
On this page
  • 1. Summary
  • 2. Abstract
  • 3. Motivation
  • 4. Status
  • 5. Specification
  • 6. License

Was this helpful?

  1. SmartBCH Evolution Proposals (SEPs)

SEP109: On-chain Verification of Verifiable Random Functions

PreviousSEP102: Adjustment of Used GasNextSEP18: Blockchain cheques on smartBCH

Last updated 2 years ago

Was this helpful?

1. Summary

This SEP specifies a precompiled contract which can verify VRFs (Verifiable Random Functions).

2. Abstract

A is the public-key version of a keyed cryptographic hash. Only the holder of the private key can compute the hash, but anyone with public key can verify the correctness of the hash. It is very hard to implmenent VRF using EVM's bytecode, since VRF needs a lot of computations on eliptic curves. So on smartBCH, we implement VRF using the native language (Golang) and expose its interface as a precompile contract, which has a predefined address: 10003.

3. Motivation

Verifiable random functions are very useful in electing a random quorum in a fair way. They have been used in some blockchains, such as Algorand, VeChain and harmony.one.

If smart contracts can support VRFs, on-chain governance can also use them in electing quorems, which will benefit smartBCH's ecosystem.

4. Status

This SEP was already deployed at the XHedge upgrade.

5. Specification

The smart contract at the address of 0x0000000000000000000000000000000000002713 can verify VRFs. It takes a byte string as input, which contains the following information:

  1. Alpha (byte 0~31), this is the preimage to be hashed. Although IETF's standard allows variable-length alpha, on smartBCH only fixed length preimages are supported.

  2. Public Key (byte 32~64), this is a 33-byte compress public key for the secp256k1 curve.

  3. Pi (bytes 65~end), this is the proof for hashing.

It returns 32-byte output data and a status code. When Public Key and Pi are valid, the status code is 1 and the 32-byte output data is hash result of Alpha; when any of them is invalid, the status code is 0 and the output data are all zeros.

Example usage in solidity:

	function verify(uint alpha, bytes calldata pk, bytes calldata pi, bytes calldata beta) external returns (bool) {
		require(pk.length == 33, 'pk.length != 33');
		(bool ok, bytes memory retData) = address(0x2713).call(abi.encodePacked(alpha, pk, pi));
		return ok && keccak256(retData) == keccak256(beta);
	}

6. License

The content is licensed under .

CC0
Verifiable Random Functions
SEP-100: On-chain Verification of Verifiable Random Functions
1. Summary
2. Abstract
3. Motivation
4. Status
5. Specification
6. License