Ultra light client #103
                  
                    
                      kimurayu45z
                    
                  
                
                  started this conversation in
                IBC Ideas
              
            Replies: 1 comment
-
| Threshold signature scheme is based on the number of shared, how to adapt that to staking based? | 
Beta Was this translation helpful? Give feedback.
                  
                    0 replies
                  
                
            
  
    Sign up for free
    to join this conversation on GitHub.
    Already have an account?
    Sign in to comment
  
        
    
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
When I consider the competition between IBC and LayerZero, LayerZero is not better than IBC at all as a TAO layer, but I can conclude that even after IBC Eureka, LayerZero has slight competitiveness with the advantage of cost of "Ultra Light Node".
Ultra Light Node can be regarded as a light client model using Oracles to provide the block headers.
The cost of this should be lower than ZK light client.
Proposal
How about supporting "Ultra Light Client of Cosmos Hub in Ethereum" as a function of Cosmos Hub?
The implementation can be like using Secp256k1 ECDSA Threshold Signature Scheme of Cosmos Hub validators.
ZK Light Client still can be like "ZK light client SDK" to establish P2P IBC connection between VM chains and sovereign Cosmos SDK chains, which can keep IBC full trustless protocol.
Users can choose whether
after seeing the trustlessness of ZK light client connection between Cosmos Hub and Ethereum as a show case.
In this case, LayerZero will completely lose the competitiveness against IBC Eureka, and Cosmos Hub will have greater revenue.
Beta Was this translation helpful? Give feedback.
All reactions