Could multisig accounts controlled by witnesses be used for new chain features?
Due to the new sidechain proposal I was thinking about the tension between the understandable desire people have for new features to be integrated into the main Steem chain and the difficulty of doing a hardfork (and getting buyin from exchanges to support a hardfork) which limits what can be implemented in the main chain. And I started thinking about multisig accounts, and how they to some extent can already function like a decentralized consensus mechanism. So would it be possible to create an account that is multisig controlled by the top 20 witnesses, add code to the witness software to initiate/sign new transactions from that account to implement whatever functionality is needed, and in essence get some new features that are de facto chain-level features without a hardfork (i.e. they're equivalently trustworthy to the chain as a whole, since they would be signed by enough witnesses that could do a hardfork if they wanted)? For example, it could implement the Steem side of bridge functionality from one or more other chains.
How would it work?
I'm not an expert on these features, so let me know if you see any issues that prevent this from working, but here's the basic idea: Someone creates a new "special" account (like @null or @steem.dao) and set its multisig control weights to be evenly distributed among the top 20 witnesses (I think ideally you'd want to allow the rotating lower-rank witness to participate but I'm not sure how you'd do that simply). Then, in the witness software, after it does the normal work of processing a block, it also does whatever new functionality supports the new feature (say, check another chain for wrapped Steem tokens being sent to the bridge), and then create/sign the corresponding transaction from the special account here. Then, once a sufficient number of witnesses have signed it to cross the threshold set by the multisig parameters, it gets processed as a normal transaction to do what is needed (say, it transfers the Steem tokens from this side of the bridge to whatever their final destination is). And in addition to whatever other functionality it's doing, it would also check who the current top-20 witnesses are and issue/sign a transaction to update the multisig weights on the special account if necessary. And because this functionality would be implemented "between" normal block-processing it wouldn't have the constraint of needing to be finished in 3-second cycle times but by a more relaxed "by the time your next witness slot comes around", so it might even be possible to implement ambitious features like an EVM.
Basically, I think it could do what a sidechain could do, but because it's being implemented by the same block-processors as the main chain the features could plausibly be called features of the main chain and wouldn't need separate buyin. What do people think? Would it work? Are there issues that didn't occur to me?
@tipu curate
;) Holisss...
--
This is a manual curation from the @tipU Curation Project.
Upvoted 👌 (Mana: 5/7) Get profit votes with @tipU :)
Your idea is clever in theory... but only in theory. So from now I'll presume that you are simply interested in tech and you are not a developer yourself.
First when you say "Then, in the witness software, after it does the normal work of processing a block, it also does whatever new functionality supports the new feature" you have to know that the witness software 'steemd' is the Steem blockchain itself. (Even if some nodes are not signing block and some other services are running around)
Then you are missing a fundamental of Steem, it has many good features but it's not meant to do heavy computation (like ethereum) and has no native support for other chains (like thorchain). so when you say "it also does whatever new functionality" Steem would need to execute arbitrary logic based on new arbitrary function/feature (called smart contract on other chains) stored on chain and using the Steem consensus. Remember the Steem blockchain only validate and process predefined operations (comment,vote,etc...) and Steem is using custom_json operation to compensate the lack of smart contract but for that it requires a sidechain. But ok let say we have smart contracts on chain (this would be a big challenge even for Dan Larimer), the following assumption is still wrong And because this functionality would be implemented "between" normal block-processing it wouldn't have the constraint of needing to be finished in 3-second cycle You probably think that witnesses have extra time between blocks but no, they don't have it, all nodes operates in a schedule, if you add any heavy computation to a node you will end up with congestion or worse multiple forks. Heavy computation would probably also mean that Steem would become a chain where you pay fees for each transaction rather than using RC.
I can continue like this and point out more misunderstanding but I guess you understand what I mean, Steem has not been designed in this way. A big change like this on the mainnet is clearly not easy as you think and would require years of work and test from an experienced team in C++ to be done. Again I'm not saying it's impossible but do you imagine anyone willing to take the risk to make a change like this on a working mainnet? Or pay a team of few devs for 3-4-5 years and up to millions to simply reproduce what some others are doing better? (since they are designed for it). It would be much easier to make a new chain in that case and implement the social features on it.
In opposite a sidechain like in the proposal avoids these issues by running an independent consensus mechanism designed for custom logic (like an EVM). Let the consensus of Steem witnesses focused on block production, without forcing them to run extra logic, all while providing a bridge where transactions are cryptographically validated rather than relying on off-chain agreements.
No, it would need to implement whatever function/feature was being added, not necessarily smart contracts.
Can you expand on what you mean by that? Perhaps walk through a hypothetical example of what happens when a witness node is overloaded.
Can you?