search

singnet / snet-daemon

Service Daemon exposes an AI application as an API that is accessible through the SingularityNET Network. It handles all interaction with the blockchain for authorization and payment using AGI tokens and passes through API calls to the AI application.
MIT License
46 stars 49 forks source link

Alternative to ETCD - POC #405

Open anandrgitnirman opened 5 years ago

anandrgitnirman commented 5 years ago

Do a quick POC to have an alternatiive storage for channel state , we are looking at redis / cockraoch DB . We are also looking at making the Daemon even more generic to support an alternate storage

stellarspot commented 5 years ago

There is a description why ETCD has been chosen as the payment channel data storage: https://github.com/singnet/wiki/blob/master/payment-channel/PaymentChannelStorage.md

The main idea was the data storage for payment channel need to satisfy Consistency requirements in CAP theorem.

What side of the CAP theorem does Redis satisfy?

The quick search gave me a link www.credera.com

Redis Cluster was designed as a general solution for high availability and horizontal scalability for all users of the database. As such, it was designed from the ground up with the major value additions to Redis in mind: performance and a strong data model. Because of this, Redis Cluster implements neither true availability nor consistency of the CAP theorem.

astroseger commented 5 years ago

@anandrgitnirman Why ETCD is a problem?

The architecture of current system is based on assumption that storage has strong consistency. If we use storage without strong consistency then we open ourselves to different kinds of attacks and troubles (the simplest problem --- cluster partition). It seems you cannot solve these problems without strong consistency.

anandrgitnirman commented 5 years ago

@astroseger , As a platform we are looking at enabling other Storage systems, giving the service provider more flexibility , this excercise is only a POC to see how compatible we are to allow for different storages ( Agree , there needs to be strong consistency) .

anandrgitnirman commented 5 years ago

There is a description why ETCD has been chosen as the payment channel data storage: https://github.com/singnet/wiki/blob/master/payment-channel/PaymentChannelStorage.md

The main idea was the data storage for payment channel need to satisfy Consistency requirements in CAP theorem.

What side of the CAP theorem does Redis satisfy?

The quick search gave me a link www.credera.com

Redis Cluster was designed as a general solution for high availability and horizontal scalability for all users of the database. As such, it was designed from the ground up with the major value additions to Redis in mind: performance and a strong data model. Because of this, Redis Cluster implements neither true availability nor consistency of the CAP theorem.

hi @stellarspot , thanks for Sharing all the details , I have changed the description , goal is to also see how easy it is to on board a new DB ( totally agree with you and @astroseger ) that we need to strong consistency

vsbogd commented 5 years ago

Different service providers may have different requirements on performance and availability. Some of them may even not need distributed databases. And using another db instead of ETCD may significantly simplify setup for them. So adding different db integrations to daemon makes sense.