Terabethia - A Bridge and Messaging Protocol between Ethereum and the Internet Computer.

Overview

Frame 644 (1)

Terabethia - A Bridge Between Ethereum & the Internet Computer

Terabethia is a bridge between Ethereum & the Internet Computer that contracts in both chains can use to message each other, and that Ethereum assets (ERC20, ERC721, & ERC1155) can use to be automatically mirrored & used on the IC through Terabethia's Magic Proxy & Token Factory, which will deploy wrapped versions of those assets programmatically with equivalent standards on the IC (DIP20, DIP721, DIP1155).

Important: This is an early look at Terabethia's repository, but it does not reference the final or upcoming test-net implementation. Don't consider the repository as a stable or complete release yet. We will further document, polish, and add-in key pieces to the Magic Proxy, the bridge, and more soon.

On this repository you can find early iterations of:

  • eth: The Ethereum side of the Terabethia bridge and its contract.
  • ic: The Internet Computer side of the Terabethia bridge and its contract.
  • serverless: The base serverless AWS service utilized by the bridge.

Terabethia's Bridge Protocol Architecture

Group 5972 (3)

As seen in the graphic above, Terabethia's architecture is composed of the following pieces:

  • Terabethia (Ethereum): One end of the bridge, the protocol's contract on Ethereum.
  • Terabethia (IC): The other end of the bridge. The protocol's contract on the IC.
  • State Sync Infrastructure: An AWS/lambda (for now) infra to send messages Ethereum<->IC.*
  • The Magic Proxies: Contracts for the Ethereum asset mirroring protocol. Token Factory: Service in charge of deploying mirrored token contracts on the IC.

The State Sync Infrastructure will be removed from AWS once the native IC/Ethereum integration goes live (at which point this piece can be built in a canister on the IC). However starting with this piece being centralized is common practice for many bridges.

Terabethia's Magic Proxy Flow

Group 5974 (1)

One of the magic pieces is that it includes a built-in wrapped token factory on the Internet Computer that's in charge of deploying the mirrored ERC20 contracts to the IC using equivalent standards we've developed: DIP20, DIP, 721, & DIP1155 (coming soon).

There are two magic proxy contracts, one on Ethereum and another on the Internet Computer that can communicate with each other through Terabethia. 

They will automatically allow anyone to send ERC20 tokens (and soon ERC721 & ERC1155) to the IC and benefit from its L2-like benefits (low fees, fast transactions, etc.) and other unique features (enhanced compute/storage capabilities, hosting/serving front ends directly from smart contracts, native IC/ETH integration, etc.) without needing to modify or rewrite any contracts or code.

Comments
  • chore: out going message store

    chore: out going message store

    Description

    • Add MAX_OUTGOING_MESSAGES_COUNT constant
    • Add .with_capacity for messages_out HashSet
    • Add payload size validation in inspect_message. Now incoming messages with a payload bigger than 1.9MB are rejected before executing the call.

    Changes

    • store_outgoing_message now returns Err if max outgoing messages amount is reached.
    opened by fcavazzoli 1
  • chore: starknet.js integrate new tooling

    chore: starknet.js integrate new tooling

    Starknet goerli has introduced fees into their network. Starknet.js deprecated a few functions that we use on AWS to send calls to the goerli testnet.

    opened by b0xtch 1
  • Fix/claimable get token pid

    Fix/claimable get token pid

    Description

    New

    • Add token_name to ClaimableMessage struct

    Fix

    • Get token canister id from token_eth_address as principal before calling dip20proxy in order to remove the claimable message
    opened by fcavazzoli 1
  • feat(DAB): retry failed registrations

    feat(DAB): retry failed registrations

    Description

    Retry failed calls to DAB performed from the magic_bridge

    Feat

    • Define a candid method that triggers a flush of failed_canisters list calling DAB again in order to get the new canisters registered.
    • If the call fails again, a counter is incremented in order to be able to have track of the amount of times that the canister have been retried
    opened by fcavazzoli 1
  • feat(DAB): DIP20 implementation

    feat(DAB): DIP20 implementation

    Description

    DAB integration

    Feat

    • DIP20 registration in DAB Token. This means that every canister created by magic bridge gets automatically registered in DAB.
    • If the registration fails for whatever reason, the transaction performed by the magic bridge does not rollback, the canister is created anyways. But we save the parameters that were used to call DAB so the call can be retried later
    opened by fcavazzoli 1
  • Fix: withdraw pending balance

    Fix: withdraw pending balance

    Description

    • Add magic_bride call in dip20_proxy to get token canister id
    • add ClaimableMessage if send message is success for both eth and dpi20 proxy

    Changes

    • New attributes definition for Withdraw withdraw(eth_contract_as_principal: TokendId, eth_addr: EthereumAddr, _amount: Nat,)
    • New struct pub struct WithdrawableBalance(pub Vec<(String, String, Nat)>)
    opened by fcavazzoli 0
  • feat: Update Claim Asset Flow

    feat: Update Claim Asset Flow

    Use CAP to store ClaimableMessages

    We are doing this to avoid having to call remove_claimable after the user withdraws the asset on ETH side. Since CAP is scalable, remove_messages is no longer necessary.

    • remove_claimable candid method is going to be deleted.
    • get_claimable_messages candid method is going to be deleted because that query is being handled by CAP root.

    Next

    • after perform some test. If everything works, delete the entire folder aws/ledger.
    • add a lambda to get starknet txHash with msg_key as param.

    Frontend

    • [x] Query CAP instead of the proxy
    • [ ] Use the lambda to fetch tx_status using starknet sdk. (this is not required but it would be an awesome improvement to user experience)
    opened by fcavazzoli 0
  • chore: add cap as storage service for claimable messages

    chore: add cap as storage service for claimable messages

    Description

    Changes:

    • Upgrade cap_cdk to 0.2.4
    • Store bridged assets (IC -> ETH) in CAP
    • delete candid method remove_claimable_asset since now they are stored in CAP
    • delete candid method get_claimable_messages because that query now needs to be perform to CAP root.
    • Add CAP-Route canister id as a constant in the proxies.
    • Use insert_sync method provided by cap_cdk to store the transactions
    • Update upgrade script to save all pending transactions in cap_cdk and now thats the only use for ProxyState.unclaimed_messages.
    opened by fcavazzoli 0
  • Inspect msgs before executing the calls

    Inspect msgs before executing the calls

    #38

    • [ ] Inspect msgs before executing the calls
      • [x] 2MB limit on the calls, on all our canisters
      • [ ] inspect_message on all our canisters
        • [ ] Tera core
          • [x] Implementation
          • [ ] deploy (botch)
          • [ ] Test n Merge (Fede)
        • [ ] DIP20 proxy
          • [ ] Implementation
          • [ ] deploy (fede)
        • [ ] Eth_proxy
          • [ ] Implementation
          • [ ] deploy (fede)
        • [ ] Magic_bridge
          • [ ] Implementation
          • [ ] deploy
          • Role Authorization
    opened by fcavazzoli 0
  • chore: validate slice len < 30 when call Principal::from_nat

    chore: validate slice len < 30 when call Principal::from_nat

    Description

    • Improve implementation Principal::from_nat(nat: Nat) now this function return Result<Principal, String> and its Error when Nat slice is longer than 29, this prevents a posible panic!
    opened by fcavazzoli 0
  • chore: use update instead of query for get_messages method

    chore: use update instead of query for get_messages method

    Description

    Use update call instead of query for get_messages candid method on tera core.

    With this change now agent-js will check subnet signature on the response.

    opened by fcavazzoli 0
  • Feat: retry handle message

    Feat: retry handle message

    Description

    Core

    • Add candid method nonce_exist to check if the nonce has been consumed or not

    Proxies

    • Add candid method message_exist to check is the hash is in the proxy awaited for being consumed.
    opened by fcavazzoli 0
  • Chore/improve eth contracts

    Chore/improve eth contracts

    Description

    ETH Proxy:

    • Add Ownable
    • Add Pausable
    • Emit Init event with constructor params.
    • Lock solidity version to 0.8.17
    • Improve overall testing

    ERC20 Proxy

    • Add Ownable
    • Add Pausable
    • Add Whitelist of tokens (only Owner can modify this list)
    • Add Blacklist of tokens (only owner can modify this list)
    • Lock Solidity version to 0.8.17
    • Emit init event with constructor params
    • Improve overall testing.
    opened by fcavazzoli 1
  • chore: use ic-kit to improve inter canister calls

    chore: use ic-kit to improve inter canister calls

    • version 0.5 unreleased ic-kit, wait for it
    • instead of serializing and decerelizaing the responses from inter-canister calls we can simplify the call to only return us what we need, like rejection codes and responses
    opened by b0xtch 0
Owner
Psychedelic
Decentralized product studio focused on building products on Web3, Ethereum, and the Internet Computer.
Psychedelic
Dank - The Internet Computer Decentralized Bank - A collection of Open Internet Services - Including the Cycles Token (XTC)

Dank - The Internet Computer Decentralized Bank Dank is a collection of Open Internet Services for users and developers on the Internet Computer. In t

Psychedelic 56 Nov 12, 2022
A preview of the integration between Bitcoin and the Internet Computer.

Bitcoin Integration Developer Preview Overview The integration between the Internet Computer and Bitcoin will enable developers to build canisters tha

DFINITY 39 Sep 21, 2022
Source project for the Internet Computer software

The Internet Computer is the world’s first blockchain that runs at web speed and can increase its capacity without bound. Like the Internet (which is composed of many machines adhering to TCP/IP protocol) and blockchain protocols (such as Bitcoin and Ethereum).

DFINITY 1.2k Jan 1, 2023
DIP721 - An Internet Computer Non-fungible Token Standard

DIP721 - Introduction DIP721 is an ERC-721 style non-fungible token standard built mirroring its Ethereum counterpart and adapting it to the Internet

Psychedelic 48 Nov 24, 2022
Rust library for build smart contracts on Internet Computer, by the Spinner.Cash team.

Spinner Rust library for building smart contracts on the Internet Computer. More specifically it is used by Spinner.Cash, a decentralized layer-2 prot

Spinner 6 May 31, 2022
A demo of the Internet Computer's Bitcoin API

Bitcoin Integration Demo A demo of the bitcoin endpoints on the Internet Computer. This demo is already deployed to the IC, so you can already try it

Islam El-Ashi 8 Jul 2, 2022
Simple PoC to issue JSON Web Tokens (JWTs) with a canister on the Internet Computer.

JWT Issuer Proof of Concept Overview Simple PoC to issue JSON Web Tokens (JWTs) with a canister on the Internet Computer. It allows the issuance of tw

Dominic Wörner 7 Oct 13, 2022
Simple node and rust script to achieve an easy to use bridge between rust and node.js

Node-Rust Bridge Simple rust and node.js script to achieve a bridge between them. Only 1 bridge can be initialized per rust program. But node.js can h

Pure 5 Apr 30, 2023
An open source desktop wallet for nano and banano with end-to-end encrypted, on chain messaging using the dagchat protocol.

An open source wallet with end-to-end encrypted, on chain messaging for nano and banano using the dagchat protocol.

derfarctor 22 Nov 6, 2022
A value transfer bridge between the Monero blockchain and the Secret Network.

Secret-Monero-Bridge A value transfer bridge between the Monero blockchain and the Secret Network. Proof-of-Concept Video Demonstration: https://ipfs.

null 28 Dec 7, 2022
A Rust implementation of the Message Layer Security group messaging protocol

Molasses An extremely early implementation of the Message Layer Security group messaging protocol. This repo is based on draft 4 of the MLS protocol s

Trail of Bits 109 Dec 13, 2022
A bridge between different serde implementations.

serde-bridge   Bridge between serde types Quick Start use anyhow::Result; use serde_bridge::{from_value, into_value, FromValue, IntoValue, Value}; fn

Xuanwo 14 Nov 24, 2022
Ethereum (and Ethereum like) indexer using P2P message to fetch blocks and transactions

Ethereum P2P indexer This project is an indexer for Ethereum and Ethereum forks. It takes advantage of the ETH (Ethereum Wire Protocol) to fetch block

null 5 Nov 10, 2023
Substreams development kit for Ethereum chains, contains Firehose Block model and helpers as well as utilities for Ethereum ABI encoding/decoding.

Substreams Ethereum Substreams development kit for Ethereum chains, contains Rust Firehose Block model and helpers as well as utilities for Ethereum A

StreamingFast 15 Oct 25, 2022
Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.

Themis provides strong, usable cryptography for busy people General purpose cryptographic library for storage and messaging for iOS (Swift, Obj-C), An

Cossack Labs 1.6k Dec 30, 2022
Dione is an anonymize and encrypted messaging system build on top on a peer to peer layer.

Secure and Anonymous Messaging WARNING: Currently Dione is not ready to be used nor does it fulfill its goal of being an anonymous messenger. In order

Dione 41 Jan 5, 2023
An encrypted multi client messaging system written in pure Rust

?? Preamble This is a pure Rust multi-client encrypted messaging system, also known as Edode's Secured Messaging System. It is an end-to-end(s) commun

Edode 3 Sep 16, 2022
Glommio Messaging Framework (GMF) is a high-performance RPC system designed to work with the Glommio framework.

Glommio Messaging Framework (GMF) The GMF library is a powerful and innovative framework developed for facilitating Remote Procedure Calls (RPCs) in R

Mohsen Zainalpour 29 Jun 13, 2023
MangoBOX is a fork and upgrade of fund-raising protocol Juicebox on Ethereum.

Mangoboxink MangoBOX is a fork and upgrade of fund-raising protocol Juicebox on Ethereum. It rewrites the logic and functions of Juicebox in the smart

Mangobox 0 Oct 13, 2022