# Indy vs TrustChain

## Development
Both projects are open source

Indy:
- community based
- amount is very limited
- no paid developers

TC:
- paid developers to boost core technology
- active development
- easy to share current knowledge base
- same approach as Evernym: first develop a stable technology, then onboard a community
- possibility to start as a technology leader

## Programming Language

Indy: Python

TC: Typescript
- type based language, better to read than python
- lots of libraries
- fast implementation, no development from scratch for different technologies (db usage, logging, etc.)
- in case of abandoned dependencies they can be forked and fixed
- easy to learn, huge developer community

Why not Go or Rust:
- lack of libraries
- no requirements for resource intensive tasks like large file encoding, AI (crypto algorithms are performed in Rust)
- Support of Web Assembly allows to transform TS-based algorithms into Rust ones when required
- Horizontal scalability used for performance increase (much easier to scale up containers than overoptimizing an algorithm at the beginning)

## Internal structure

Indy:
- Python process, not able to scale it
- monolith application
- rare code documentation

TC:
- microservice architecture for different tasks (wallet handling, p2p network, parsing, storing, etc.)
- modular approach, allows to replace components in the future (e.g. the wallet has to be written in Go, it can be used with the other services via redis and tcp calls)
- Only start the required services (monitoring, different type of wallet service)

## Deployment
Indy:
- binary that can be run in the VM
- Docker container

TC:
- Only docker containers
- development is independent from used programming language, easy to change components in the future
- Able to run only the required services, managed via a docker-compose file
- allows horizontal scaling

## Monitoring
Indy:
- validator info transaction

TC:
- Prometheus: measuring microservices performance and other metrics
- Loki: Access to logs for debugging, analyzing without accessing the machine
- Grafana: Monitoring multiple nodes via multiple instances, support for alerts
- Healthchecks: generating base load to make sure consensus and other services are available. Alerting admins when necessary.
- Auto recovery: node is able to find anomalies to get back to a healthy status
- Cost reduction: other admins are able to identify problems from the logs other nodes to send a restart request

## P2P Network

Indy:
- fully meshed network
- all nodes are taking part in the consensus
- all nodes are available to the internet
- different port for consensus and read/write requests
- Usage of resource intensive ZEROMQ protocol

TC:
- Observer/Gateway-Pattern: Distribution of the tasks: validators only perform the consensus, gateways are validating the transactions before passing them to the consensus and observers act as read nodes for external read calls
- Using Web Sockets for connection: allows to run an observer or gateway without a public IP-address
- Using TLS for secure transfer

## Consensus
Indy:
- plenum, resource intensive with large amount of nodes

TC:
- TBFT, build on IBFT, linear resource usage

## Trust
Indy:
- state proof, validators have signed the state of the transaction
- using latest genesis file to validate signatures of the proof (validator needs file that matched with the signature, could have changed due to key rotations)

TC:
- Validating chain of trust back to the genesis block

## SSI Support
Indy:
- full support of Anoncreds
- full privacy focus
- currently only credential format with full ZKP capabilities
- stores all information in a new transaction when updating a DID

TC:
- VC support
- All resources are designed as DIDs to be called via a universal resolver
- Only stores changes of a DID in a transaction

Both systems are able to support VCs and Anoncreds with different transaction types.

## Hierarchy

Indy:
- stewards can write
- validators build consensus and manage the roles

TC:
- gateways can write
- validators build consensus and manage the roles
- observers can read
- clients can write when having the permissions

## Business Model
Both solutions are permissioned based so license models or pay per use models are possible. For pay per use the amount of transactions is counted and sent as an invoice, no cryptocurrency involved.

# Possible questions

## No one is familiar with TrustChain technology
- Open source only since November 2021
- Paper has been reviewed by several companies, no negative feedback
- Already a production network out there for two years, used by universities and companies

## How will the business model
- License and Pay per use approach like planned with Indy

## What does TrustCerts get out of it
- Need a consortium to run the network, has no incentives like crypto currencies like Cheqd
- Gets feedback for features, bugs, etc.
- IDunion SCE is a perfect candidate to run it
- based in Europe

## How to invest
- If a change is intended, an investment in a deletion concept at Indy makes little sense.

## There are no wallets out there to use it right now
- SSIs is an ongoing process
- focus on the long run to have a stable tech stack

## Next steps
- Using TrustChain for cases that want to use VCs
- Setting up a parallel network to evaluate the VDRs
- Merging Anoncreds Cases on TrustChain when Anoncreds are fully supported

Link to evaluation: https://nextcloud.idunion.org/apps/files/?dir=/AP6-F%26E/Dual-Tech%20Strategy&openfile=125431