Giter VIP home page Giter VIP logo

centrifuge-chain's Introduction

GitHub Actions Workflow Status codecov GitHub Release Substrate version License
Twitter URL Telegram

Centrifuge

Centrifuge Chain

The layer-1 blockchain for real-world assets, built on Substrate.
Read the documentation Β»

About Centrifuge

Centrifuge is the infrastructure that facilitates the decentralized financing of real-world assets natively on-chain, creating a fully transparent market which allows borrowers and lenders to transact without unnecessary intermediaries. Asset pools are fully collateralized, liquidity providers have legal recourse, and the protocol is asset-class agnostic with pools for assets spanning mortgages, invoices, microlending and consumer finance. Ultimately, the protocol aims to lower the cost of borrowing for businesses around the world, while providing DeFi users with a stable source of collateralized yield that is uncorrelated to the volatile crypto markets. By bringing the entire structured credit market on-chain across securitization, tokenization, privacy, governance, and liquidity integrations, Centrifuge is building a more transparent, affordable, and limitless financial system.

Building blocks

On top of the Substrate FRAME framework, Centrifuge Chain is composed of custom pallets which can be found inside the pallets folder. The following list gives a brief overview, and links to the corresponding documentation:

  • anchors (docs): Storing hashes of documents on-chain. The documents are stored in the Private Off-chain Data (POD) node network.

  • anchors-v2 (docs): Second version of the pallet used to store document hashes on-chain.

  • block-rewards (docs): Provides means of configuring and distributing block rewards to collators as well as the annual treasury inflation.

  • bridge (docs): Connecting ChainBridge to transfer tokens to and from Ethereum.

  • collator-allowlist (docs): Tracking active collators, and allows the root account to manage this list.

  • ethereum-transaction (docs): Wrapper around the Ethereum pallet which allows other pallets to execute EVM calls.

  • fees (docs): Taking fees from accounts and sending this to the treasury, to the author, or burning them.

  • foreign-investments (docs): Enables investing, redeeming and collecting in foreign and non-foreign currencies. Can be regarded as an extension of pallet-investments which provides the same toolset for pool (non-foreign) currencies.

  • interest-accrual (docs): Keeping account of the outstanding debt through interest accrual calculations.

  • investments (docs): Provides orders for assets and allows user to collect these orders.

  • keystore (docs): Linking public keys to accounts. Supporting the operations of the offchain document consensus layer through the Centrifuge POD (Private Offchain Data) Node.

  • liquidity-pools (docs): Provides the toolset to enable foreign investments on foreign domains.

  • liquidity-pools-gateway (docs): The main handler of incoming and outgoing Liquidity Pools messages.

  • liquidity-pools-gateway-queue (docs): The queue used by the Liquidity Pools Gateway for processing inbound/outbound messages.

  • liquidity-pools-gateway-routers (docs): This crate contains the DomainRouters used by the Liquidity Pools Gateway pallet.

  • axelar-gateway-precompile (docs): Pallet that serves as an EVM precompile for incoming Liquidity Pools messages from the Axelar network.

  • liquidity-rewards (docs): Epoch based reward system.

  • loans (docs): Locking a collateral NFT into a pool allowing to borrow from the pool. The loans pallet is also used for bookkeeping loan values and outstanding debt.

  • oracle-collection (docs): Pallet used to collect and aggregate oracle values.

  • oracle-feed (docs): Pallet used to feed oracle values.

  • order-book (docs): Allows orders for currency swaps to be placed and fulfilled.

  • permissions (docs): Linking roles to accounts. It is adding and removing relationships between roles and accounts on chain.

  • pool-fees (docs): Stores all the fees related to a pool and allows for these fees to be charged.

  • pool-registry (docs): Used for creating, updating, and setting the metadata of pools.

  • pool-system (docs): Creating and managing investment pools. It is bundling loans, slicing pools into tranches, and controlling investment epochs.

  • restricted-tokens (docs): Transferring tokens and setting balances. It is wrapping orml-tokens with the addition of checking for permissions.

  • restricted-xtokens (docs): Wrapper pallet over orml-xtokens which allows the runtime to create arbitrary filters for transfers of x-chain-transfers.

  • rewards (docs): Implement a scalable reward distribution mechanism that can be used for other pallets to create different rewards systems.

  • swaps (docs): Enables applying swaps independently of previous swaps in the same or opposite directions.

  • token-mux (docs): Enables proxying variants of the same foreign assets to a local asset representation.

  • transfer-allowlist (docs): This pallet checks whether an account should be allowed to make a transfer to a receiving location with a specific currency.

Developing

Instructions for building, testing, and developing Centrifuge Chain can be found in docs/DEVELOPING.md.

License

This codebase is licensed under GNU Lesser General Public License v3.0.

centrifuge-chain's People

Contributors

akhilesharora avatar astox avatar branan avatar cdamian avatar dependabot[bot] avatar gpmayorga avatar gruberb avatar ivanceras avatar jaybutera avatar juniuszhou avatar lemunozm avatar lucasvo avatar mikiquantum avatar mustermeiszer avatar nunoalexandre avatar omahs avatar philipstanislaus avatar pstehlik avatar stanly-johnson avatar tankofzion avatar thea-leake avatar vedhavyas avatar vimukthi-git avatar wischli avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

centrifuge-chain's Issues

[timebox] Research/Model for state rent calculations

  • Research into state tree design

    • Estimate the cost of different items stored. Eg: transactions, anchors
    • How can we store anchors in the tree efficiently(indexed buckets vs ttl trie) while allowing for
      • Efficient query by ID
      • Off-chain purge + verifiability after purge(may be with child tree headers)
      • Model long term behavior of each algo (math vs statistical model)
  • How different actors in the system would benefit/lose out with different designs

https://centrifuge.hackmd.io/3YhROyWbQY68s6dQM6AB1w

Deploy "permanent" instances for "load testing"

To be able to test out state growing - there should be a permanent deployment to test with.

  • Deploy to GCP with two validators
  • Manual deploy OK via spinnaker/kube
  • tear down once testing is over

Implement extend op code for anchors

Exactly like commit except

Anchor data is to be retrieved using GetByAnchorID
Cost calculation should take into account difference between new and last evictedate
(Probably no need to delete the previous storage as it would get evicted)

Investigate fee configuration on substrate

Following things needs to be researched/investigated

  • List of payable transactions in Cent chain
  • How does setting transaction fee weights(gas) work?
  • Can we set gas amounts on genesis instead of having it hard coded.
  • Can we still use fee module to setup fee configurations (hooks?)

cc @pstehlik

Implement Evict

Evict
On a certain evict date = 𝑇𝑒𝑣𝑖𝑐𝑑
Get the root of the evicted child tree = 𝑅𝑒𝑣𝑖𝑐𝑑𝑒𝑑=π‘β„Žπ‘–π‘™π‘‘_π‘ π‘‘π‘œπ‘Ÿπ‘Žπ‘”π‘’_π‘Ÿπ‘œπ‘œπ‘‘(𝑇𝑒𝑣𝑖𝑐𝑑)
Delete all anchors for the date -> π‘π‘™π‘’π‘Žπ‘Ÿ_π‘β„Žπ‘–π‘™π‘‘_π‘ π‘‘π‘œπ‘Ÿπ‘Žπ‘”π‘’(𝑇𝑒𝑣𝑖𝑐𝑑)
Set the root for the evict date -> πΈπ‘£π‘–π‘π‘‘π‘‘πΆβ„Žπ‘–π‘™π‘‘π‘†π‘‘π‘œπ‘Ÿπ‘Žπ‘”π‘’π‘…π‘œπ‘œπ‘‘π‘ .𝑝𝑒𝑑(𝑇𝑒𝑣𝑖𝑐𝑑,𝑅𝑒𝑣𝑖𝑐𝑑𝑒𝑑)

Delete indexes:
𝑖=πΏπ‘Žπ‘‘π‘’π‘ π‘‘πΈπ‘£π‘–π‘π‘‘πΌπ‘›π‘‘π‘’π‘₯=>𝑖𝑑=π΄π‘›π‘β„Žπ‘œπ‘ŸπΌπ‘›π‘‘π‘’π‘₯𝑒𝑠.𝑔𝑒𝑑(𝑖)=>π΄π‘›π‘β„Žπ‘œπ‘ŸπΈπ‘£π‘–π‘π‘‘π·π‘Žπ‘‘π‘’π‘ .π‘Ÿπ‘’π‘šπ‘œπ‘£π‘’(𝑖𝑑)=>π΄π‘›π‘β„Žπ‘œπ‘ŸπΌπ‘›π‘‘π‘’π‘₯𝑒𝑠.π‘Ÿπ‘’π‘šπ‘œπ‘£π‘’(𝑖)

until a evict date is found that is more than 𝑑𝑒𝑣𝑖𝑐𝑑

set πΏπ‘Žπ‘‘π‘’π‘ π‘‘πΈπ‘£π‘–π‘π‘‘πΌπ‘›π‘‘π‘’π‘₯ to last removed index

Set up dynamic test accounts on Cent Chain for functional tests

Centralized way to create Cent Chain test accounts
All the functional tests and apps will require pre-funded test accounts.
Possible solution:

  • write a small JS script that funds test accounts from Alice (or another genesis account with lots of value)

Implement GetByAnchorID with index

GetByAnchorID
Make sure that the β€œgetByAnchorId” does not return anchor data after evict date has been reached.
This solves the issue that the bucket might be evicted already and the index is still existing. -> Then the evict has to assure that it clears the index one after another.

given anchor id = 𝐴𝐼𝐷
𝑑𝑒𝑣𝑖𝑐𝑑=π΄π‘›π‘β„Žπ‘œπ‘ŸπΈπ‘£π‘–π‘π‘‘π·π‘Žπ‘‘π‘’π‘ .𝑔𝑒𝑑(𝐴𝐼𝐷) => O(1)
π‘Žπ‘›π‘β„Žπ‘œπ‘Ÿπ·π‘Žπ‘‘π‘Ž=π‘Ÿπ‘’π‘Žπ‘‘_π‘β„Žπ‘–π‘™π‘‘_π‘ π‘‘π‘œπ‘Ÿπ‘Žπ‘”π‘’(𝑑𝑒𝑣𝑖𝑐𝑑,𝐴𝐼𝐷) => 𝑂(𝑙𝑒𝑛(π‘π‘œπ‘›π‘π‘Žπ‘‘(𝑑𝑒𝑣𝑖𝑐𝑑,𝐴𝐼𝐷))) => 𝑂(1)

Implement child tree based anchor buckets and commit extrinsic


// child storage for anchor data represented as a double map
AnchorStorage: Map EvictDate => AnchorID => AnchorData

#### Commit

Anchor data = $AnchorData$
Anchor ID = $AID$
Commit date = $t_{commit}$
User defined evict Date = $t_p$
Calculate User defined anchor period = $p_u$ = $t_p$ - $t_{commit}$
System defined minimum anchor period = $p_s$
Calculate actual anchor period = $p_{actual}$ = {$p_u$ < $p_s$ ? $p_s$ : $p_u$} (properly define case stmt :)
Calculate actual evict date = $t_{evict}$ = $t_{commit}$ + $p_{actual}$

**Store in child storage** -> $set\_child\_storage(t_{evict},  AID, AnchorData)$
**Store evict date index** -> $AnchorEvictDates.put(AID, t_{evict})$
**Calculate anchor index** = $AIDX = CurrentAnchorIndex + 1$
**Store anchor index** -> $AnchorIndexes.put(AIDX, AID)$
**Store current anchor index** -> $CurrentAnchorIndex = AIDX$

Total storage per anchor = $S_{anchor} = 2 * storage(AID) + storage(AnchorData) + storage(AIDX)$
Cost per storage unit per time unit = $c_{unit}$
Calculate anchor storage cost = $c_{storage} = S_{anchor} * c_{unit} * p_{actual}$  

Const gas cost (gas) = $c_{insert}$
Total tx cost = $c_{tx} = c_{storage} + c_{insert}$

complexity = $O(1)$ since trie inserts costs at most length of the anchor id string and its a fixed length hash.

Implement rent calculation for state on anchors

Once we have the implementation for storage of anchors we need to implement the actual rent for state using the fee module.
Total storage per anchor = π‘†π‘Žπ‘›π‘β„Žπ‘œπ‘Ÿ=2βˆ—π‘ π‘‘π‘œπ‘Ÿπ‘Žπ‘”π‘’(𝐴𝐼𝐷)+π‘ π‘‘π‘œπ‘Ÿπ‘Žπ‘”π‘’(π΄π‘›π‘β„Žπ‘œπ‘Ÿπ·π‘Žπ‘‘π‘Ž)+π‘ π‘‘π‘œπ‘Ÿπ‘Žπ‘”π‘’(𝐴𝐼𝐷𝑋)
Cost per storage unit per time unit = 𝑐𝑒𝑛𝑖𝑑
Calculate anchor storage cost = π‘π‘ π‘‘π‘œπ‘Ÿπ‘Žπ‘”π‘’=π‘†π‘Žπ‘›π‘β„Žπ‘œπ‘Ÿβˆ—π‘π‘’π‘›π‘–π‘‘βˆ—π‘π‘Žπ‘π‘‘π‘’π‘Žπ‘™

Deploy testnet with "real" genesis

Instead of taking the pre-defined testnet with Alice/bob/... the deployment should have a more realistic genesis file:

  • generate different accounts than Alice/Bob/..
  • specific root account with passed in public key for each testnet
  • setting up the initial authorities for the chain validation

[bug] Fulvous testnet error with storage root invalid

When running fulvous, node panics with,

====================

stack backtrace:
   0: substrate_panic_handler::set::{{closure}}::h22f0f1d19b29e46d (0x5570318b0ec0)
   1: std::panicking::rust_panic_with_hook::h057ff03eb4c8000f (0x5570319e9a59)
             at src/libstd/panicking.rs:478
   2: std::panicking::begin_panic::h01337335381120d3 (0x557031539645)
   3: srml_executive::Executive<System,Block,Context,UnsignedValidator,AllModules>::execute_block::h46420a4b51db8b11 (0x55703153d8ac)
   4: centrifuge_chain_runtime::api::dispatch::h63face78c359dd4d (0x557031514a8d)
   5: std::panicking::try::do_call::h62e7477d6f4b75b4 (0x557030f33692)
   6: __rust_maybe_catch_panic (0x5570319eedea)
             at src/libpanic_unwind/lib.rs:85
   7: substrate_executor::native_executor::safe_call::h3cbd82ffde27a0a3 (0x557030cc9728)
   8: std::thread::local::LocalKey<T>::with::h8e36660e2af3b325 (0x557030a53127)
   9: <centrifuge_chain::service::Executor as substrate_executor::native_executor::NativeExecutionDispatch>::dispatch::h0913301dcc5bbd02 (0x557030891792)
  10: std::thread::local::LocalKey<T>::with::hada49c4683f7f063 (0x557030a5be3e)
  11: substrate_state_machine::StateMachine<H,N,B,T,O,Exec>::execute_aux::h4c4976f3f2d5fbc8 (0x557030e0ca66)
  12: substrate_state_machine::StateMachine<H,N,B,T,O,Exec>::execute_call_with_native_else_wasm_strategy::h7a70dacfe7719c17 (0x557030e12122)
  13: <substrate_client::call_executor::LocalCallExecutor<B,E> as substrate_client::call_executor::CallExecutor<Block,substrate_primitives::hasher::blake2::Blake2Hasher>>::call_at_state::hf54a9cd0e8c0c6eb (0x557030d9af96)
  14: <&substrate_client::client::Client<B,E,Block,RA> as substrate_consensus_common::block_import::BlockImport<Block>>::import_block::h3b2cc48f55fe45c5 (0x557030a024b8)
  15: <substrate_finality_grandpa::import::GrandpaBlockImport<B,E,Block,RA,PRA,SC> as substrate_consensus_common::block_import::BlockImport<Block>>::import_block::hfa4176c6ffcdc91b (0x557030f173d6)
  16: <substrate_consensus_babe::BabeBlockImport<B,E,Block,I,RA,PRA> as substrate_consensus_common::block_import::BlockImport<Block>>::import_block::hf4b1416a1336ff4f (0x557030e56cce)
  17: core::task::poll::Poll<T>::map::h2800644b173cd077 (0x557030b0bd38)
  18: <futures_util::try_future::map_ok::MapOk<Fut,F> as core::future::future::Future>::poll::h44e75c53666d861d (0x5570307e100c)
  19: futures_util::try_future::try_chain::TryChain<Fut1,Fut2,Data>::poll::hf94a03e42d347958 (0x557030e3a9ad)
  20: <futures_util::try_stream::try_for_each::TryForEach<St,Fut,F> as core::future::future::Future>::poll::h1e4058bc162f42bf (0x557030b1ca59)
  21: futures_util::future::chain::Chain<Fut1,Fut2,Data>::poll::h7e04c1afbe139a43 (0x5570307eacda)
  22: <futures_util::compat::compat03as01::Compat<Fut> as futures::future::Future>::poll::h8dbc10bf30d58049 (0x557030ef3776)
  23: <futures::future::select::Select<A,B> as futures::future::Future>::poll::h61fa2b5b8f541b6a (0x557030c31b2a)
  24: futures::future::chain::Chain<A,B,C>::poll::h6107eb89c39c9da2 (0x557030ea93ec)
  25: <futures::future::map_err::MapErr<A,F> as futures::future::Future>::poll::hf2217414ed5ab382 (0x557030d2bf3e)
  26: futures::task_impl::std::set::h1d6c7394509821f8 (0x55703173b292)
  27: std::panicking::try::do_call::h4da7ee154caa89f2 (0x55703173adf2)
  28: __rust_maybe_catch_panic (0x5570319eedea)
             at src/libpanic_unwind/lib.rs:85
  29: tokio_threadpool::task::Task::run::h0116a589554a280b (0x5570317384b9)
  30: tokio_threadpool::worker::Worker::run_task::h59c5abb9988e7e20 (0x557031731e55)
  31: tokio_threadpool::worker::Worker::run::h818f5066b41d5b52 (0x55703173132e)
  32: std::thread::local::LocalKey<T>::with::h1fcd9efb210f2dd2 (0x55703171bcde)
  33: std::thread::local::LocalKey<T>::with::h5fbd4053ce8d547c (0x55703171be9f)
  34: std::thread::local::LocalKey<T>::with::h16eaac48bb88b444 (0x55703171bb2b)
  35: tokio::runtime::threadpool::builder::Builder::build::{{closure}}::h5c979caac29cea17 (0x5570317208de)
  36: std::thread::local::LocalKey<T>::with::h01b9617282c3e29b (0x55703173ba63)
  37: std::thread::local::LocalKey<T>::with::h076aff392ca7ff3f (0x55703173bb9e)
  38: std::sys_common::backtrace::__rust_begin_short_backtrace::hd8e94618c1c47325 (0x557031733991)
  39: std::panicking::try::do_call::h9f90deaf148b6ba7 (0x55703173ae3c)
  40: __rust_maybe_catch_panic (0x5570319eedea)
             at src/libpanic_unwind/lib.rs:85
  41: core::ops::function::FnOnce::call_once{{vtable.shim}}::he5b73f6ee3ce78f5 (0x557031734610)
  42: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h805c3cc89d534c05 (0x5570319d71ff)
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/liballoc/boxed.rs:704
  43: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h9ebda9db5f03daf3 (0x5570319ee100)
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/liballoc/boxed.rs:704
      std::sys_common::thread::start_thread::ha32838ccbb8a8179
             at src/libstd/sys_common/thread.rs:13
      std::sys::unix::thread::Thread::new::thread_start::h6f10b78f26c98dc6
             at src/libstd/sys/unix/thread.rs:79
  44: start_thread (0x7f52c66166ba)
  45: clone (0x7f52c613641d)
  46: <unknown> (0x0)

Thread 'tokio-runtime-worker-1' panicked at 'Storage root must match that calculated.', /root/.cargo/git/checkouts/substrate-7e08433d4c370a21/4e1d637/srml/executive/src/lib.rs:319

This started happening after implementing child storage anchor state rent.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.