Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Harmony brings the technology of VRF (Verifiable Random Function) natively on chain to create a optimal solution for randomness that is unpredictable, unbiasable, verifiable and immediately available. Harmony VRF is a unique construction based on our existing cryptographic primitive of BLS signatures which makes the computation efficient without extra burden to our network validators. Harmony VRF is available for every single block and any smart contract can access the random output through a precompiled contract without paying additional fees.
VRF is a cryptographic invention to solve the problem of onchain randomness. VRF introduces the cryptographic construction where a private key SK is used to work on an arbitrary message and produce a unique and random output along with a proof. The validity of the random output can be verified by any one who knows the corresponding public key PK and the proof.
Harmony supports the on-chain verifiable random source based on VRF (Verifiable Random Function). Specifically, for every new block, the block producing validator computes a VRF based on his private key and the latest block hash to produce a 32-bytes VRF output and 96-bytes proof. The VRF output and proof are concatenated as a 128-bytes data and put in the VRF field of the header of the newly proposed block.
The VRF data are available to be consumed by any chain clients by querying the block header. We also exposed the VRF data in the smart contract level via a new EVM precompiled contract at address 0xff. Any smart contract on Harmony can access it with following solidity assembly code:
Note the input of the precompiled contract at 0xff is the block number for which the VRF is requested. The block number should only be within the last 256 blocks. If a block number outside this range is provided, the current block's VRF will be returned.
Harmony builds on the existing cryptographic primitive of BLS signatures which are currently used for block signing and consensus to create an efficient and secure VRF construction. The BLS-based VRF works as follows. Given a VRF input M, a BLS private key SK is first used to sign on M to produce a signature S=sign(SK, M). Then the signature is hashed with sha256 to produce the VRF random output R=hash(S), and the signature itself becomes the VRF proof P=S. The VRF output R can be verified with the proof P by checking that P is the correct signature from PK on message M and that hash(P)=R. More formally, the BLS-based VRF construction (Keygen, Compute, Verify) can be specified as follows:
Keygen(r) → (PK, SK). The BLS key generation algorithm produces a pair of public key PK and private key SK.
Compute(SK, M): Hash(Sign(SK, M)) → (R, P). The computation of VRF output R is the hashing of the signature signed with the private key SK on message M. The VRF proof P equals the signature from Sign(SK, M).
Verify(PK, M, R, P): SigVerify(PK, P, M)=True & Hash(P)=R. The verification of the VRF works by checking 1) the VRF proof P is the correct signature from public key PK and message M; 2) the VRF output R equals the hash of P.
Harmony VRF brings the opportunity for developers to build trust-worthy and fair Dapps and protocols on chain. To name a few potential applications using VRF:
Make blockchain games provably fair and entertaining by using VRF to generate random game scenarios, distribute loot fairly and shuffle players unpredictably.
Randomly and fairly assign tasks or assets to participants of DAO, DeFi or NFT.
Select a random sample of protocol validators or governance voters from all participants for consensus or decentralized governance.
With Harmony VRF, a new realm of randomness-based trust-worthy applications can be built natively on Harmony blockchain. Developers with a security-focused mindset can feel safe to build applications using Harmony’s secure on-chain randomness. It’s guaranteed by cryptography with verifiable proof that no malicious participants are able to predict or influence the random outcome and make unfair profits. Additionally, Harmony VRF is available on every block of all 4 shards in Harmony and is easily accessible through a simple smart contract call without extra fee.
Envio offers native support for Harmony (both testnet and mainnet) and has been designed to support high-throughput blockchain applications that rely on real-time data for their business requirements.
Indexers on Envio can be written in JavaScript, TypeScript, or ReScript.
HyperSync is an accelerated data query layer for the Harmony blockchain, providing APIs that bypass JSON-RPC for 20-100x faster syncing of historical data. HyperSync is used by default in Envio's indexing framework, with the use of RPC being optional. Using HyperSync, application developers do not need to worry about RPC URLs, rate-limiting, or managing infrastructure and can easily sync large datasets in a few minutes, something that would usually take hours or days using RPC.
Contract Import: Autogenerate the key boilerplate for an entire Indexer project off a single or multiple smart contracts. Deploy within minutes.
Multi-chain Support: Aggregate data across multiple networks into a single database. Query all your data with a unified GraphQL API.
Asynchronous Mode: Fetch data from off-chain storage such as IPFS, or contract state (e.g. smart contract view functions).
Quickstart Templates: Use pre-defined indexing logic for popular OpenZeppelin contracts (e.g. ERC-20).
Users can choose whether they want to start from a quickstart template, perform a subgraph migration, or use the contract import feature.
The following files are required from the user to run the Envio indexer:
Configuration (defaults to config.yaml
)
GraphQL Schema (defaults to schema.graphql
)
Event Handlers (defaults to src/EventHandlers.*
depending on the language chosen)
These files are auto-generated according to the template and language chosen by running the envio init
command.
This walkthrough explains how to initialize an indexer using a single or multiple contracts that are already deployed on a blockchain. This process allows a user to quickly and easily start up a basic indexer and a queryable GraphQL API for their blockchain application within a few minutes.
cd
into the folder of your choice and run
Name your indexer
Choose the directory where you would like to setup your project (default is the current directory)
Select Contract Import
as the initialization option.
Block Explorer option only requires user to input the contracts address and chain of the contract. If the contract is verified and deployed on one of the supported chains, this is the quickest setup as it will retrieve all needed contract information from a block explorer.
Please note: Block explorer option currently only supports networks with etherscan. If the network doesnt have etherscan, you can proceed using the Local ABI option.
Choosing Local ABI
option will allow you to point to a JSON file containing the smart contract ABI. The Contract Import
process will then populate the required files from the ABI.
config.yaml
fileNote if you are using a proxy contract with an implementation, the address should be for the proxy.
The Contract Import
process will prompt the user whether they would like to finish the import process or continue adding more addresses for same contract on same network, addresses for same contract on different network or a different contract.
Indexing can be a rollercoaster, especially for more complex use cases. Our engineers are available to help you with your data availability needs.
Join our growing community of elite builders, and find peace of mind with Envio.
is a feature-rich indexing solution that provides developers with a seamless and efficient way to index and aggregate real-time or historical blockchain data for any EVM. The indexed data is easily accessible through custom GraphQL queries, providing developers with the flexibility and power to retrieve specific information.
Designed to optimize the user experience, Envio offers automatic code generation, flexible language support, quickstart templates, and a reliable cost-effective .
Envio supports on Harmony mainnet.
HyperSync is also available as a standalone API for data analytic use cases. Data analysts can interact with the HyperSync API using JavaScript, Python, or Rust clients and extract data in JSON, Arrow, or Parquet formats. For more information, visit the HyperSync documentation .
For more information on contract import feature, visit the documentation .
Click for Envio Indexer Examples.
Email:
Graph hosted environment support harmony https://twitter.com/harmonyprotocol/status/1533909977412214784
Graph: https://graph.t.hmny.io/ Management: https://graph.t.hmny.io:8020/ Metrics: https://graph.t.hmny.io:8030/ see this link for more detail on how to create and deploy on the harmony sandbox indexer node https://docs.harmony.one/home/developers/tutorials/the-graph-subgraphs/building-and-deploying-subgraph-public-node
The Graph is only a sandbox. We do not guarantee uptime or data persistence. Projects should run their own instances and not rely on sandbox Graph.
To run Graph locally, use the official repo at https://github.com/graphprotocol/graph-node with the RPC https://a.api.s0.t.hmny.io
see more detail here https://docs.harmony.one/home/developers/learn/tutorials/the-graph-subgraphs/building-and-deploying-subgraph-local-node
horizon-bridge-subgraph is built to support querying http://bridge.harmony.one/
This page describes how to use ganache-cli to connect to Harmony networks.
Install Ganache CLI
Load Harmony networks (local, testnet, mainnet) to ganache-cli. The command below loads
Use web3.js to interact with the ganache binded harmony network
A web3-react toolkit for Harmony wallets
Harmony-React is not a fork of web3-react, but rather built on top of web3-react to ensure that the library can be upgraded whenever web3-react gets updated.
Add web3-react/core
and the wallets you want to use (OneWallet, MathWallet or both) to package.json
:
Install using yarn install
or npm install
.
Import packages:
Instantiate wallets:
Store the wallet references in a store or a suitable structure, e.g:
Create a wallet connection/unlock modal (or other suitable UI element):
Implement the Unlock
component:
And finally, implement the WalletComponent
:
For full reference implementations of Store
, UnlockModal
, Unlock
, and WalletComponent
:
adds support for using OneWallet and MathWallet together with .
For a more in-depth implementation example check .
Store
:
UnlockModal
:
Unlock
:
WalletComponent
:
This page explains how to get the latest price of ONE and other HRC20 assets inside smart contracts, using the Chainlink Price Feed on Harmony.
To consume price data, your smart contract should reference AggregatorV3Interface
, which defines the external functions implemented by Price Feeds.
The latestRoundData
function returns five values representing information about the latest price data. See Price Feeds API Reference for more details.
Sample output when you run the above code:
We will go through each of these steps:
Requesting data using BandChain.js library
Using BandChain data in EVM Smart Contract in Harmony
BandChain provides the BandChain.js JavaScript library so developers can submit data requests right from their dApp client.
Once BandChain has successfully executed the requested oracle script, it will return the data and EVM proof payload back to the client to then be passed to our smart contracts in harmony blockchain.
Here is an example simple Node file requesting data using the library that queries the current Bitcoin(BTC) price from BandChain.
Now let’s go through each section of the code.
Import the library and declare the necessary variables:
The code requires two libraries:
@bandprotocol/obi.js: a helper library to assist us when encoding/decoding data to/from Band Protocol’s OBI standard
@bandprotocol/bandchain.js: the library that we’ll be using to make the queries to BandChain
Now, set the request parameters:
Here we set the values that we will be using to make the request
endpoint
: the endpoint we will make the query to
mnemonic
: the mnemonic we will use to make the query. The associated account must have a balance to make a request
bandchain
: contains the necessary functions we’ll need to make the request
oracleScript
: object containing details of the oracle script we will be querying
minCount
: the minimum number of BandChain’s validators that responds for us to consider the request successful
askCount
: the maximum number of validators that we want to respond to the request
Now make the Oracle request and get the random hash:
Finally, we execute the submitRequestTx
member function of the previously declared bandchain object to make the oracle data request.
We can then do one of two things with regards to this request:
Call getRequestResult
, as we did here, to get the actual result of the request
Call getRequestProof
to get the proof bytes associated with the request
Both of these functions take in one argument, the requestID
of the request you want to retrieve the result/proof from.
If the query is successful, the code should print a value similar to:
{ price: 11406282500000n }
,
which is the retrieved price of Bitcoin multiplied by 1 billion.
Now that we know how to make a request to BandChain and retrieve the corresponding proof, we will now examine how we can use that proof in our smart contract.
The code below demonstrates an example contract that retrieves the latest price of Bitcoin from Band’s bridge contract and saves it onto the contract’s state:
Okay, now let’s break down the code.
Aside from OpenZeppelin’s SafeMath.sol, the contract we will be writing requires three helper files specific to Band’s oracle and bridge architecture: Obi.sol
, Decoders.sol
, and IBridgeWithCache.sol
.
This contains a set of functions to help serialize and deserialize binary data when interacting with the BandChain ecosystem. The full standard specification can be found on their wiki and the code on the BandChain repository.
This is what we will use to work with data related to requests made on BandChain. This will help us in extracting the various information, such as the price value, we may need from the request response from Band’s oracle. The file is available from an oracle script’s bridge code tab on the devnet explorer. For this particular example, the code is available here.
The interface file for Band’s bridge contract. The code for this can also be found on the BandChain repository.
Now let’s look at the contract itself:
The contract itself can then be further broken down into two parts: the constructor
and the main getPrice
function.
The contract’s constructor takes one argument, the address of the bridge contract. It then sets the various fields of the req RequestPacket
variable. This req variable will be what we will use as the key to match and retrieve the price from the bridge contract. Specifically, in this case, we set req to have the following parameters.
bridge
: the address of Band’s bridge contract on the blockchain this example contract is deployed to. See this list for the chains that Band currently supports and corresponding contract addresses. You can deploy the bridge contract by yourself on the harmony chain. Bridge contract can be found here.
clientId
(“from_scan”): the unique identifier of this oracle request, as specified by the client.
oracleScriptId
(76): The unique identifier number assigned to the oracle script when it was first registered on Bandchain.
params
(hex”00000003425443"): The data passed over to the oracle script for the script to use during its execution. In this case, it is hex representation of the OBI-encoded request struct
minCount
(4): The minimum number of validators necessary for the request to proceed to the execution phase
askCount
(4): The number of validators that are requested to respond to this request
This is then the main function that we will use to fetch the price from Band’s bridge contract and save it into our price database contract’s state. It calls the bridge contract’s getLatestResponse to retrieve the latest request response associated with a BTC/USD price request. It then uses Decoders.sol’s decodeResult method to parse that response into a struct. Finally, we save the price value from that response into the contract’s price variable.
Examples can be found here https://github.com/harmony-one/band_oracle
https://github.com/harmony-one/band_oracle/blob/main/main.js
https://github.com/harmony-one/band_oracle
contract's been deployed and you can call getPrice
or getMultiPrices
to get actual prices
Band’s StdReference contract for testnet 0xE740092E081CA7491A46C8Aa0175446e962e2A08
mainnet contract is coming soon
A quick guide on how to verify your contracts on Harmony.
https://explorer.harmony.one/verifycontract
Right now, we support verification only for one single solidity file - therefore, before deployment and verification, you will need to flatten all solidity sources to one file.
To flatten your solidity files we recommended to use https://www.npmjs.com/package/truffle-flattener
Or you can use any other flattener lib
To more easy verification we recommend to deploy contract with Harmony Remix https://docs.harmony.one/home/developers/deploying-on-harmony/using-remix/deployment-using-remix
You can verify your contract here https://explorer.harmony.one/verifycontract
Important to use correct params (the same like on deploy):
Contract address
Contract name
Compiler version
Optimizer
Chain Type (mainnet or testnet)
Sources
Imported libs
Then click Submit button
If all parameters are correct - you should to see Success
message, or Error
if bytecodes don't equal
On Success case - you contract will verify and you will see all contract details on contract explorer page
https://docs.soliditylang.org/en/develop/abi-spec.html
To get ABI-encoded constructor arguments you can ue this service: https://abi.hashex.org
Example for Harmony Remix:
1 - click ABI to copy it
2 - paste ABI to https://abi.hashex.org form and click parse
3 - paste your constuctor arguments and click Copy
4 - paste encoded constructor arguments to verify form field