Generally the technical setup is done by a local Platform Service Provider like Grassroots Economics. The more local the better.
- Open Source (CopyLeft) Software: Ensure that you trust the software being used and that even if it is open source now, that improvements and upgrades will remain open source. Check out our stack.
- Distributed Ledger: We highly recommend developing your own ledger system where members of the community hold nodes that decentralize and secure the ledger.
- Interfaces / Wallets: We’ve built custodial systems that enable users to assign guardians that can help them reset lost passwords.
- Data Sharing: Given the consent of the community, anonymous transaction data can be recorded and displayed
CIC Stack Summary¶
While work toward non-custodial and web interfaces are underway, the CIC Stack is currently a custodial wallet and blockchain bidirectional interface engine for community inclusion currencies
- Fully Open source GPL 3.0 License
- Automates the full lifecycle of blockchain transactions
- Chain agnostic by design
- Introduces a new chain library toolset written from scratch
- Modular design with fully standalone but recombinable components
- Includes a broad collection CLI tools for most common chain and engine operations
- Empowers implementers to choose their level of abstraction
- Supports both local, containerized and decentralized environments
- Support last mile front-end apis and integrations
- Base components, containing all necessary provisions for services and tooling. (Chaintools)
- Generic services components, libraries, daemons and services making up the custodial engine. (cicnet)
- Deployment components, which facilitates deployment of the custodial engine, as well as seeding data for development, demonstration and migration. (GrassrootsEconomics)
- Test Coverage
- Queue handling (chainqueue): Makes sure that a transaction sent on behalf of a user is sent, resubmitted if stalled, and whose execution is verified by quering the network state.
- Chain syncing, (chainsyncer): Retrieves all state changes from the network and executes an arbitary number of code fragments per transaction.
- RPC (Remote Procedure Call) interface, which divides in two parts:
- Chain tooling (chainlib, chainlib-eth): Granular access to all conceptual layers of chain interaction, including binary serializations and application interfaces, along with CLI (Command Line Interface) tooling framework.
- Signer, (crypto-dev-signer) Low-security keystore and signer which is easily usable in both production (provided that no external access is possible) and in any development environment.
- Configuration (confini): Incrementally merging configuration definition from multiple modules, and easily overriding them with command line flags and environment variables.
Generic services components¶
- All smart contract wrappers in the cicnet repository.
- CIC Contract registry (cic-eth-registry): Defines token and resource pointer lookup and authentication resources.
- Daemons and microservices in the apps subdirectories in the cic-internal-integration monorepo, specifically:
- cic-eth: Massively parallel and fault-tolerant implementation of the custodial signer/queuer/syncer engine, accepting tasks from end-users via middleware.
- cic-cache: Cache syncer and database fetching and storing details on transactions of interest.
- cic-ussd: State machine, microservices and gateway for end-users using the USSD (Unstructured Supplementary Service Data) interface via telcos.
- cic-notify: Pluggable notification engine, initially used only for SMS notifications to end-users.
- Data seeding and/or migrations for new development deployments. Located in the apps/data-seeding subdirectory of cic-internal-integration.
- Deployment and initialization of network resources (smart contracts etc) and initialization of the custodial engine. Located in the apps/contract-migrations subdirectory of cic-internal-integration.
Components by category¶
(in no particular order)
|chain queue/sync base||any||chainqueue, chainsyncer||Louis||?||py||mid||hi|
|chain queue/sync engine||custodial||cic-eth, cic-eth-registry, cic-signer||Louis||Phil||py, celery||hi||hi|
|ussd wallet||custodial||cic-ussd||Phil||?||py, celery||hi||hi|
|wallet interface translations||any||cic-translations||Will?||Phil||yaml?||lo||hi|
|HTTP authentications||custodial||usumbufu, cic-auth-helper||Louis||Blair, Sohail||py||hi||hi|
|python chain libaries||any||chainlib-eth, chainlib,||Louis||(community?)||py||mid||hi|
|python signer libraries||any||funga, funga-eth||Louis||?||py||mid||hi|
|local queue and sync||non-custodial||chaind, chaind-eth, cic-batch||Louis||?||py||mid||?|
|contract interfaces||any||cic-contracts, eth-erc20, eth-owned, erc20-faucet, eth-interface||Louis||?||solidity, py, bash||mid||hi|
|ge token contract||any||erc20-demurrage-token, sarafu-faucet||Louis||?||solidity, py||hi||hi/lo|
|verificable claims base||any||okota||Louis||?||solidity, py||mid||hi|
|cic analytics and aggregator||custodial||cic-data-golang||Blair||Darren||golang||mid||mid|
|cic analytics views||custodial||cic-data-golang||Darren||?||grafana, golang?||mid||?|
|web2 metadata store||custodial||cic-meta||?||Louis||typescript||mid||hi|
|metadata protocol||any||crdt-meta||~~Spence~~||~~Geoff~~, Louis||typescript||mid||hi|
|contributor badge nft||non-custodial||(rose bootcamp project), nft-badgetoken||solidity, py, typescript, react(?)||Rose||Louis||mid||lo|
|web3 transition adapters||any||fadafada, fadafada-curl||Louis||(community?)||rust||mid||mid|
|cli cic creation||any||cic-cli||Phil||Louis||py||hi||mid|
|cli metadata viewer||custodial||clicada, cic-staff-installer||?||Louis||py||lo||lo|
|ge blog||website||pelican website||Ida||Will||py, pelican||lo||hi|
|ge docs||website||docs webstie||Will||?||py, (platform)?||mid?||mid|
|local dev bootstrap||devops||cic-stack||?||all||bash, docker-compose||hi||hi|
|dev data seeding / migration||any||cic-stack||Phil||Louis||py, bash, typecsript||hi||hi|
|chain queue/sync interface||custodial||cic-eth-server, ...||Lum||?||py||?||?|
|Web2 wallet||custodial||social recovery protocol||Lum||?||?||?||no|
|P2P Services discovery||any||cic-p2p, village message protocol||Louis||?||?||?||?|
|Gas helpers||any||cic-gas-proxy, ethd-gas-sum||Louis||?||py||lo||lo|
|Swarm provisions||non-custodial||libswarm-ng, pylibswarm||Louis||(community?)||c, py||mid||hi|
("Relative complexity" means complexity in relation to the function of the component.)
There are the requirements to run our complete software stack:
- 3 x (2 CPU, 4GB RAM, 50+ GB Storage) for validator nodes future proofed for 1 yr across different cloud providers/data centers.
- n x (1 CPU, 2GB RAM) for prunning state nodes, useful for non-custodial web3 users tx submissions.
- Kubernetes preffered
- 4 CPU, 8GB RAM, 50+ GB Storage minimum (Includes additional monitoring components)