Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discovery and concensus: research and discussion. #184

Open
goodboy opened this issue Dec 29, 2020 · 3 comments
Open

Discovery and concensus: research and discussion. #184

goodboy opened this issue Dec 29, 2020 · 3 comments
Labels
discussion experiment Exploratory design and testing help wanted Extra attention is needed

Comments

@goodboy
Copy link
Owner

goodboy commented Dec 29, 2020

This is a draft issue that I hope gets filled out more and more by lurkers over time.

The road map has the following:

  • custom cross-host supervisors
  • mult-host service architecture tooling
  • support for planet scale msg patterns and systems

But in order to do these things we need both a service discovery system (presumably by relying on a (set of) protocols) and, a modern concensus system which these days is usually in the form of either a centralized algo such as raft or, the thoroughly more pumped distributed equivalents.

Here are some resources to start poking at for research and tinkering:

As always, lurkers engage.

@goodboy goodboy added help wanted Extra attention is needed discussion experiment Exploratory design and testing labels Dec 29, 2020
@guilledk
Copy link
Collaborator

guilledk commented Dec 29, 2020

Crypto pump is here:

BFT options:

  • Proof of Work: not appropriate to the use case and also highly inefficient
  • Proof of Stake: more efficient but also has possible centralization issues
  • Delegated Proof of Stake: even more efficient than PoS but with similar centralization issues (video 3:04)

I'm currently working in a startup developing decentralized applications on the DPoS blockchain Telos, Its a fork of the bigger EOS blockchain.

Some good things about it:

  • Smart Contract language is C++ uses llvm backend
  • Resource model is great CPU/NET is practically free as you just need to stake a bit of tokens, RAM is what you need for storing permanent information in the blockchain, but as with any token you are free to sell it at any point getting your money back or even making a profit.

Basically every time you need for example, voting or an escrow you can write your backend in a smart contract and interact with it from python.

The service discovery could be saved in a ledger inside a smart contract

DOCS

@goodboy
Copy link
Owner Author

goodboy commented Dec 29, 2020

thanks @guilledk, got any links on performance tradeoffs by chance?

No rush either.

@gc-ss
Copy link

gc-ss commented May 12, 2021

Hashicorp has some great, single binary (so deployment is not a challenge) solutions to:

custom cross-host supervisors
mult-host service architecture tooling

Hashicorp Nomad

we need both a service discovery system (presumably by relying on a (set of) protocols) and

Hashicorp Consul

a modern concensus system which these days is usually in the form of either a centralized algo such as raft

Hashicorp Consul also exposes their battle tested raft library https://github.com/hashicorp/raft

https://www.hashicorp.com/resources/everybody-talks-gossip-serf-memberlist-raft-swim-hashicorp-consul

@goodboy goodboy changed the title Discovery and concensus: the long view of actor model architectures. Discovery and concensus: research and discussion. Jul 4, 2021
goodboy added a commit that referenced this issue Aug 28, 2023
By spawning an actor task that immediately shuts down the transport
server and then sleeps, verify that attempting to connect via the
`._discovery.find_actor()` helper delivers `None` for the `Portal`
value.

Relates to #184 and #216
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion experiment Exploratory design and testing help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants