Post-Launch Roadmap - Proposal: Atom Transfers
Welcome! This forum topic is for community discussion of the “Proposal: Atom Transfers” item on the Post-Launch Roadmap.
A proposal has been created here which would enable transfers and links to this page. I thank the proposal authors (“Simply VC”) for their efforts and look forward to enabling transfers, but I (individually, not representing any official entity) have serious concerns with this proposal as written. Specifically: Network upgrade process: dual-proposal vs. single-proposal I think a dual-proposal process for software upgrades would be safer and provide a higher degree of certainty for node operators (particularly validators). Such a system would have first an indicative proposal to demonstrate stakeholder approval of a particular milestone (such as 0.34.0 ), and then once software development was completed and the software version released / tested, a second proposal with an exact code hash and block height would facilitate the network upgrade. I think compressing these two proposals into a single one, which preapproves the software release, may introduce undesirable levels of uncertainty and risk. The Cosmos SDK development team - or any future development team working on the Cosmos Hub software - could change the contents of a milestone or the code within a software release…
Excerpt (1199 of 3548 characters). Read the whole post on the forum ↗
IMO the proposal doesn’t defer authority to the github milestone but does defer to judgement of any of the private keys of the following IDs to define the release. It is legitimate for the Cosmos Hub governance to delegate authority to some specific parties to sign github commits.
the Tendermint development team (identified by keybase IDs DBB0B3EC64A4BDAA,
0979483D4F669CFF, 37AA68F6AA20B7A8) push a new release (v0.34.0) of the Cosmos SDK;
It is legitimate for the Cosmos Hub governance to delegate authority to some specific parties to sign github commits.
I don’t follow why the github commit has to be signed here as far as governance is concerned. I agree with Chris’s proposal, in that model governance would first define what it is that they want. Then there is a purported commit that meets that, and is purportedly tested. Governance then votes on if they think that hash is sufficiently tested, and if so when to upgrade / how. However the commit hash will be on chain, so there was no need for a third party to sign that hash.
Are you instead proposing an alternate system, where cosmos governance delegates defining of the next feature set to a third party entity? (The “commit signer”?)
yes the model I am proposing here is basically one where the Cosmos governance specifies the general direction it wants to go and delegates authority on final code to the tag signer.
Mostly I think this fine because we aren’t trying to create a machine readable/checkable system here. We simply trying to signal intent and layout a process the validators need to follow to produce a successor chain to cosmoshub-1
On this topic, the following conversation took place in a Cosmos community-managed ICO Delegator/Validator/Dev Telegram chat room about 10 hours ago. “Dev” is ValarDragon and “J K” is Jae Kwon: Christopher Goes: My concerns about the 2nd governance proposal (primarily around upgrade process) - Post-Launch Roadmap - Proposal: Atom Transfers Adrian Brink: +1 Andrew @ Figment Networks: Agree with Adrian and Chris. We should approve a specific software commit hash. Zaki Manian: That strategy means a miminium of two weeks from final commit to release and if any bugs are found a 2 week reset Basically pushes transfers enabling to early may which is a fine thing to want but there should be an understanding of the constraints of this strategy Adrian Brink: Giving final authority to 1 person to decide what code will be run feels eerily similar to the EOS arbitration process. Instead of sending around a signed pdf with the correct commit hash, it’s a digital signature. Christopher Goes: I’m not sure the proposal does that, it isn’t specified what the AiB auth process is exactly. Maybe they meant that all three PGP keys must sign. Zaki Manian: It still…
Excerpt (1194 of 20187 characters). Read the whole post on the forum ↗
It is great to see such a discussion about our proposal and we would like to clarify the rationale behind the proposal. We believe that the Tendermint development team have, to date, taken great care to release an application of great quality, ensuring that releases meet the required standards before allowing for their actual use. In fact, we are able to have governance proposals discussing changes to the mainnet chain today due to their work and this approach. It is conceivable to us that we can trust the team to deliver a new release of excellent quality. In line with this, and given the lack of a formal structure through which the community can decide on release features, acceptance criteria and final approval process, we proposed that the team is given the power to finalise a new release that will also enable the transfer on the network. The proposal also gives the development team the leeway to stop the release should anything come up which they deem might jeopardise the stability and security of the network (see last paragraph of the Proposed upgrade process section) We are aware that this is not the only way forward and that a two or even three step approach could…
Excerpt (1197 of 1769 characters). Read the whole post on the forum ↗
what is the telegram link
Yeah I am strongly of the opinion that trying to make a giant leap from a team controlled release process to governance controlled release performance on the 1st post launch release has a lot of downside risks and limited upside.
I think the goal of moving the governance to a more primary role in upgrades and managing code hashes makes sense but should evolve over time.