Open gentso09 opened 3 years ago
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
This issue now has a funding of 3000.0 USD (2998.5 USD @ $1.0/USD) attached to it.
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Work has been started.
These users each claimed they can complete the work by 9 hours from now. Please review their action plans below:
1) samarth9201 has started work.
Implement Rosetta API 2) vaibhavgeek has started work.
Rosetta SDK implementation for VITE 3) blake256 has started work.
Rosetta Node API For Vite
Learn more on the Gitcoin Issue Details page.
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Work for 3000.0 USD (2998.50 USD @ $1.0/USD) has been submitted by:
Prize Title
Rosetta Node API for Vite
Prize Bounty
$3000 in VITE + VITE merch
Challenge Description
Looking for someone to build the Rosetta Node API for Vite (https://vite.org). Vite is an asynchronous, message-driven blockchain using a high-performance DAG-based ledger structured called block-lattice.
Rosetta is an OpenAPI standard (https://www.rosetta-api.org/docs/welcome.html) that makes integrating with blockchains simpler, faster, and more reliable. The Rosetta API is made up of 2 core components, the Data API and the Construction API. See Rosetta Data API Overview and Rosetta Construction API Overview for details.
You can use any convenient programming language to implement the API. Rosetta provides the rosetta-sdk-go (https://github.com/coinbase/rosetta-sdk-go) to facilitate the work, which means if you are familiar with Golang, you could save a lot of time by using the SDK.
Future maintenance is not required after the final approval of your work.
Submission Requirements
Judging Criteria
Winner Announcement Date
Resources
Follow Vite on social media
Vite Rosetta API Implementation Guideline
Vite Rosetta API Implementation Guideline
Network
/network/list
Returns a list of NetworkIdentifiers that the Rosetta server supports.
Vite Rosetta API Implementation Guideline
Network
/network/list
Returns a list of NetworkIdentifiers that the Rosetta server supports.
Input example:
Output example:
- The Rosetta server should identify what environment it is deployed in. The "network" field should be "testnet" or "mainnet".
/network/options
This endpoint returns the version information and allowed network-specific types for a NetworkIdentifier. Any NetworkIdentifier returned by
/network/list
should be accessible here.Input example:
Output example:
- "REQUEST" includes sending a transfer or calling a smart contract. - "RESPONSE" stands for receiving a transfer or executing a contract function. - "MINT" is the Coinbase transaction, including issuing SBP rewards and minting new token. - "errors" should include all error types that could be used by the API.
/network/status
This endpoint returns the current status of the network requested. Any NetworkIdentifier returned by
/network/list
should be accessible here.Input example:
Output example:
Block
/block
Get a block by its Block Identifier. If transactions are returned in the same call to the node as fetching the block, the response should include these transactions in the Block object. If not, an array of Transaction Identifiers should be returned so /block/transaction fetches can be done to get all transaction information.
Input example:
Output example:
- On Vite, a block indicates snapshot block, not account block. An account block is a transaction, and will be used in /block/transaction. - Use snapshot block related API, such as
ledger_getSnapshotBlockByHash
orledger_getSnapshotBlockByHeight
./block/transaction
Get a transaction in a block by its Transaction Identifier.
Input example:
Output example:
- "related_transactions" should be populated to identify the corresponding request transaction (having "direction": "backward") or response transaction (having "direction": "forward"). - Use
ledger_getAccountBlockByHash
Account
/account/balance
Get an array of all AccountBalances for an AccountIdentifier and the BlockIdentifier at which the balance lookup was performed.
Input example:
Output example:
- Should be able to query the balance of any token by tti. - Use
ledger_getAccountInfoByAddress
to get balance.Construction
/construction/derive
Derive returns the AccountIdentifier associated with a public key.
Input example:
Output example:
/construction/preprocess
Preprocess is called prior to /construction/payloads to construct a request for any metadata that is needed for transaction construction given (i.e. account nonce). The options object returned from this endpoint will be sent to the /construction/metadata endpoint UNMODIFIED by the caller (in an offline execution environment)
Input example:
Output example:
- No need to populate fee related fields since there is no fees on Vite. - There is no "status" for operations during construction. - "fetch_previous_hash" should be set to true by default. - "use_pow" should be set to false by default.
/construction/metadata
Get any information required to construct a transaction for a specific network. Metadata returned here could be a recent hash to use, an account sequence number, or even arbitrary chain state.
Input example:
Output example:
- "account_identifier" indicates from which address the transaction will be sent. - "account_block_height" and "previous_block_hash" are required to construct a transaction. You should get them from the blockchain by calling 1. [RPC]
ledger_getLatestAccountBlock
or 2. [Vite.js]getPreviousAccountBlock
in AccountBlock class - "difficulty" and "nonce" should be returned if “use_pow” is “true” in the request. "difficulty" can be obtained by callingledger_getPoWDifficulty
, and "nonce" is fromutil_getPoWNonce
. If “use_pow” is not set, the two fields should not be populated./construction/payloads
Payloads is called with an array of operations and the response from /construction/metadata. It returns an unsigned transaction blob and a collection of payloads that must be signed by particular AccountIdentifiers using a certain SignatureType.
Input example:
Output example:
- On Vite, there is request transaction (A sends to B) and response transaction (B receives a tx from A). If "blockType" is 2, it is a request transaction. In this case, "sendBlockHash" is not required. For response transaction (having "blockType" 4) , "sendBlockHash" must be present. - For constructing a response tx, in other words, receiving a transaction sent by others to you, you should call
ledger_getUnreceivedBlocksByAddress
to get the un-received tx list, then populate "sendBlockHash". - "unsigned_transaction" is the raw transaction string in Base64, simply converted from the account block object. For example,- "hex_bytes" is the raw payload. For example, you can use
Buffer.from(payloads.payloads[0]).toString('hex')
to populate this field./construction/parse
Parse is called on both unsigned and signed transactions to understand the intent of the formulated transaction. This is run as a sanity check before signing (after /construction/payloads) and before broadcast (after /construction/combine).
Input example:
Output example:
/construction/combine
Combine creates a network-specific transaction from an unsigned transaction and an array of provided signatures. The signed transaction returned from this method will be sent to the /construction/submit endpoint by the caller.
Input example:
Output example:
/construction/hash
TransactionHash returns the network-specific transaction hash for a signed transaction.
Input example:
Output example:
/construction/submit
Submit a pre-signed transaction to the node.
Input example:
Output example:
- Decode the base64 transaction string into a signed account block, then call
ledger_sendRawTransaction