Thanks for your response. Your feedback is very valuable. I didn't know about EPN, will look into it.
State producer pay as described is not proportional to the state-producer’s stake in the underlying chain. If you choose which BPs to reward by rank (as proposed) or another objective metric, it incentivizes a sybil attack.
Yes, this is a problem if state producers are chosen only by rank or other objective metric. But I meant to suggest this only as one example of a metric that governance process of a fractal could take into account when choosing state producers. It could be only one of many metrics they use in their strategy to select state producers pay. The power to choose state producers and their pay would ultimately lie in the hands of fractal's council members and preferably they should check the persons behind state producer services they are choosing (thus preventing sybil this way).
But in fact it’s already possible for DAOs to migrate between chains, so long as the DAO doesn’t hold any assets it’s not sovereign over. Especially if you consider running one's own chain a possible solution, which I think we should, then you can even simply replay all transactions from chain A on chain B to arrive at the same state (More complicated in EOSIO, because you would need to turn off TAPOS for the replay).
Is DAO implemented as an on-chain smart contract really sovereign over its own token? Let's say it wants to migrate to a new chain. For token of a typical DAO this wouldn't be a migration, it would be a fork, and the market would determine the value of DAO token on the old chain vs token on the new chain. There's nothing stopping the rest of the world from considering the old token "the real one". So migration could have a huge cost for a DAO. Consider also all the users and developers which might use the DAO token (especially if it has some utility). They will need to take action to start using the new DAO token as opposed to the old one. And if the software users use is provided by 3rd-party (like general wallet for that blockchain), it will take more than installing an update.
I guess part of this could be mitigated in a DAO designed according to the fractally philosophy: DAO could have the power to freeze all the tokens on the old chain, thus motivating everyone to move. But the cost for developers and users remains. Also, I think disagreements between DAOs and blockchains they run on will be a tendency, not an exception. In those situations, what's preventing the old blockchain from running the old token against fractals will? A blockchain has all the power to force migration into a fork.
I didn't mention it in the original post, but I imagine state producers hiding the information about which chain the DAO is running on from users and developers. "Hiding" in the sense that users and developers would not need to know what chain a DAO is running on and they would not need to make any changes if DAO decides to migrate. This is achievable by state producers presenting an API of a normal blockchain. I imagine state producer API to be equivalent to standard EOSIO API. This means that state producers could migrate a DAO, without changing anything about the interface users, developers and exchanges use. For this to work all DAO related transactions would have to go through these state producers, but I don't think that presents a problem.
This solution requires special APIs and state computation infrastructure to be run by existing block producers, which is socially and technologically difficult. You also require a community of validators to ensure the state producers remain honest. Given this technological complexity, any community willing to undertake it may as well just run their own blockchain.
If you mean user and app facing APIs, then see my response to the previous quote. Most of the additional complexity will be handled by developers and state producers. And state producers will be paid for their services. Requirement for community of validators is there for every blockchain. And for this solution it is no different: like BPs verify each other, so will state producers verify each other.
We agree on this: both running a new blockchain and running this solution introduces more complexity and additional work from the community. But I would propose to consider both long-term costs as well as short-term. In the short-term, yes, my proposed solution would take more time and effort to organize, than running a new chain, simply because it is a new type of solution and so it would require more work for developers and node operators at first. But I would argue that, once there's a precedent for this type of solution, it will actually be simpler and cheaper to run it than to run a totally new chain.
How does my solution reduce complexity for fractals? It does so by minimizing the importance of the blockchain it runs on in the beginning, by providing it with freedom to migrate if the initial choice does not work anymore. This is critical for adoption. You don't want to burden new communities with the task of choosing a blockchain. Creating a new fractals should be as easy as possible. Most of fractals (like most communities or startups), will probably fail. And that's ok, because that's how people experiment and find their place, their community. But if there are tough choices to make before creating every fractal, it will severely limit people's willingness to experiment. People should be able to start with what works now, and consider tough technical decision later. And choosing what chain to run on in the beginning is a big technical burden on fractal creators if they understand that if some day this chain won't work anymore they will have to:
I think most of the worry about violations of autonomy do not come from the fear that the underlying network validators will censor or abuse your community, but rather that the community itself will depend on state outside of the control of their own contracts, and thereby prevent their ability to resolve internal disputes by forking state.
That's a good point - most of the worries about violations of autonomy, indeed, do not come from fears that network validators will censor or abuse the community. And yet, fractally chooses to run its own chain, and I think we know that the main reasons are not the fears that EOS will censor or something. That's because there are all kinds of ways in which EOS governance process impacts fractally:
So there is another aspect to independence: freedom to choose the computing platform for your smart contracts. The solution I presented here, enables that.
A blockchain is like a land a fractal lives on. Most new fractals won't afford to have their own land and they won't posses the technical knowledge or foresight into the future, to start renting the land that will work for them forever. In line with More Equal Animals" philosophy: are you really independent if you cannot move (secede) from the land which is owned by someone else? The bigger the cost of moving the more dependent (and less independent) the fractal is. I think I mentioned most of the costs associated with migration of a fractal to show how dependent it is if it is implemented as an on-chain smart contract.
RE: Albedo: How to Decentralize Blockchains using ƒractally