Status: Completed
Project Type: Cooperative/Contest - Multiple workers can submit work and the bounty is shared
Time Commitment: Days
Experience Level: Beginner - Intermediate
Size: USD 3’000 in ICP (at time of distribution)
Deadline: -
Description
The current Bitcoin Canister on the Internet Computer only stores the set of unspent transaction outputs (UTXOs). This is not enough information to find out:
which ordinals are inside a given UTXO
to what level of rarety they belong
if they have an associated inscription
Until we have all this information on the Internet Computer, we want to encourage building a sustainable Open Internet Service that allows fetching this information from third-party indexing services using HTTPS outcalls.
Requirements
Given a UTXO return a list of ordinal (ranges)
Given an ordinal return the rarety and inscription (if available)
Calls to the canister should require cycles to cover the cycles cost of the canister to make it sustainable (similar to the Bitcoin canister itself, or the Exchange Rate Canister)
Acceptance Criteria
Open Internet Service deployed to the Internet Computer
The work has just started. We have progressive plan like this:
Similar to ICP<>ETH integration plan, we should quickly port usable Ordinals APIs to canister using Http Outcalls.
Hiro’s API looks nice, docs and usable codes are there. Wouldn’t take too long to complete.
Guys from Hiro use ordhook/chainhook to index Ordinals Data and use nodejs(Cloudflare) to serve the APIs. We can complete the task quickly because:
The RESTFUL apis are openAPI 3.x compatible, it wouldn’t be hard to generate usable rust code with types.
We can use standard candid function to serve similar API to the nodejs one.
We can contact with Hiro to get a usable API key, but we should carefully design the cache strategy to prevent we hit the limit during outcalls.
And then we can build a POC canister to serve API to IC ecosystem.
The on-chain indexer is the next step, and it is very similar to ICP<>BTC integration. We should consider a few things to be done.
To build a Ordinals Canister similar to Ord. Since we are only interested in indexing the data, we just replace the redb to canister stable structure.
Still, we can learn from Hiro’s Ordhook to make the work easier.
Last but not least, replace the outcall API to canister native API, then we can keep iterating and get more things done, for example BRC20 canister and more.
I should update this thread to keep this going. Also we are looking forward to participating the IC Bitcoin working group to discuss more.
If I may ask, I’d like to have your feedback on the function that computes the cost of the request. I pretty much used the one from the EVM RPC canister, but used the numbers found in the specs:
/// Cycles cost constants, based on
/// https://internetcomputer.org/docs/current/developer-docs/gas-cost#details-cost-of-compute-and-storage-transactions-on-the-internet-computer
pub const INGRESS_OVERHEAD_BYTES: u128 = 100;
pub const INGRESS_MESSAGE_RECEIVED_COST: u128 = 1_200_000;
pub const INGRESS_MESSAGE_BYTE_RECEIVED_COST: u128 = 2_000;
pub const HTTP_OUTCALL_REQUEST_COST: u128 = 49_140_000; // TODO: Double check (in the eth-rpc project, it is set to 400_000_000)
pub const HTTP_OUTCALL_BYTE_RECEIVED_COST: u128 = 10_400; // TODO: Double check (in the eth-rpc project, it is set to 100_000)
pub fn get_http_request_cost(
api: &RpcApi,
payload_size_bytes: u64,
max_response_bytes: u64,
) -> u128 {
let ingress_bytes = payload_size_bytes as u128 + url.len() as u128 + INGRESS_OVERHEAD_BYTES;
let base_cost = INGRESS_MESSAGE_RECEIVED_COST
+ INGRESS_MESSAGE_BYTE_RECEIVED_COST * ingress_bytes
+ HTTP_OUTCALL_REQUEST_COST
+ HTTP_OUTCALL_BYTE_RECEIVED_COST * (ingress_bytes + max_response_bytes as u128);
base_cost as u128
}
Are the base numbers different in the EVM-RPC canister from what is written in the spec to make the canister profitable? In mycomputation, should I not also add the cost of each message byte multiplied by the “HTTPS outcall request message size (per byte)”?
Thanks for reaching out about this! You should be okay using the numbers in the spec; the EVM RPC canister uses values prior to the HTTP outcall cost reduction, so that will likely change before the official release.