IBC Protocol
===

Tendermint:
- which provider the high throughput by constant factore, but it will unable to scale indefinetly for this reason.
- increase throughput will include for the node to like validating tranasaction, store all data, communicating with other validators.
- To Increase the transaction throughput, application diverstity and cost effieciency, we need to wide deployment of distributed ledger applications.
- by these we have the excution, storage must be spilit across many indepenedent consensus instances which run concurrently.

Inter chain communication protocals take bottom up approach

IBC handles authentication, ordering structured data packets b/w modules on separate ledgers.

IBC will be
- modules, other state machine components, or part of application logic on one side and other side is
- consenus protocols, ledgers, network infrastructure.

IBC Primary Purpose:
- provide realiable, authenticated, ordered communication b/w the modules; for this we have the protocol logic
- Data Relay
- send module msg, based on the relayers
- Reliability
- Flow control
- Authentication
- consensus transcript
- cryptographic commitment these are verified by the desinatino chain
- StatefulLess
- connection b/w the two chains
- Multiplexing
- Channnels,
- each connection have multiple channels that have one-many or many-one

## zaki Manian speech : IBC Part 1
- Agronic security // provide security standards for smart contracts
- sovereignty

- Open finance system in ethereum

- **Module to Module to compatibilty in cosmos** //TODO
consesus -> packet -> handler -> action

Connect and disconnect with chains
- Loom Network (gaming) // used cosmos-sdk

## Ethereum 2.0
Sharding:
Divide the blockchain into serval parts to, assign specific topic to each different blockchain

Beacon Chain : which resposible to maintain validators in each sharding chain,and POS mechanisam and slashing,
Sharding blockchains : they have own validators, and create block and validate txs.

Qudratic Sharding :
- Which is 4x times faster than Normal sharing, if we configure the each node in such way that it will validate, create block faster.
- this means that the Beacon chain is also capable to run 4x sharding chains.
- The Through put across the system will increase by 4*4 times.

State Sharding :
- node which need to include :
- validates txns and block : compute power
- and relay valid txs and broadcast to all nodes : network bandwidth
- store all the data : storage
- by the sharding process we can use local storage and access the data with out require the global state, of main chain
- **we need to resolve the cross-sharding and main global state for each sharde data avilability**

Cross Shard Txs:
- The txns b/w the two corresponding shards
- forks when send txns in two shards
- atomic failure of txs (one excuted another one failed)
- need the consensus with hetrogenous blockchains

[Agoric’s Jessie](https://github.com/Agoric/Jessie) //to Complex Objects

[Kadena’s Pact ](https://github.com/kadena-io/pact) // build Smart Contracts

- Shard chain malicious forks will be handled by the beacon chain,
- invalid blocks are handled by the shard chain (which has less security than the beacon chain).

## Data Validity Problem :
- FisherMan
- To resolve the data validity b/w the cross linking chains of beacon chain or cross-sharding chains.
- we will submit block header to other chain; we will set the timeperiod to check the block is valid or not by the honest validators.
- by these we have problems like
- the validator produce the invalid block and says it's valid: to prevent that we take some deposit amount from validator to verify that block,
- if the block is invalid then we burn his tokens.
- Cryptographic Commit Hash
- zk-Snarks works with code protocol
- we can use VDF also
## Data Avilability :

- Full Node : with verify all the transactions of each block contains all data
- Light Node : which contains only merkle proof of the block or txns to check whether tx is sucessful or not.
- but, if when we have cross-shard communication, full nodes(in shard network) are malicious and provide invalid merkle proof to beaon chain(main chain), there is no way to verify the tx in light node.
- to Avoid this issue,

Data Avilability and Validity

[Ethereum 2.0 By near protocol team](https://nearprotocol.com/blog/detailed-overview-of-ethereum-2-0-shard-chains-committees-proposers-and-attesters/)

**Attestations and smart fork choice rule :** to avoid vanila POS and family BFT
Attestations : in Ethreum2.0
- In a given time slot one validator is create the block, and the the remaining validator are attest to block by siging it.
to Avoid the forks in chain:
**Fork Choic rule :**
- means that the longest chain with unique validators in the given slot will be considered as the actual chain.
- **Lastest Message Driven**
- when the attester attest to two diffrent forks, that one with hightest time slot will be considerd as the longest chain.

**By these to Attestations and Fork chain Rule; ethereum avoided the vanila POS and BFT protocols**

- HeartBeat
- Random Number Generator (VDF)
- WASM