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 - whether due to implementation difficulties, changes in priority, addition of new features, or a whole host of other reasons (most of which are not malicious, although that could also be a concern). Github milestones are mutable - they can be edited at will. Until a software release is completed and an exact Git commit hash provided, stakeholders cannot be certain as to what software precisely they are agreeing to run.
This is my primary concern. Secondary concerns:
Unclear process for handling critical issues on the testnet
The proposal suggests a mechanism for accepting bug fixes:
Any bug fixes, as defined by the Tendermint development team, encountered during the operation of the gaia-14k testnet and committed to the master branch after the release of v0.34.0, will automatically be approved as per the endorsement of this proposal.
What does this mean? Must “approved” bug fixes necessarily be installed by validators? Is there a timeline for when such fixes could be committed (is this intended to be after Gaia-14k but before the upgrade, for example)?
Lack of clarity in genesis changes
Although it may be difficult to approve an exact new genesis file in proposals - due to the desire to export-import at the same height - I think proposals would be well-advised to include extremely explicit instructions on how the genesis file for the new network is to be changed, if at all (beyond export-import). Validators must make these changes manually themselves, and it is essential that they change exactly the same fields in exactly the same way, or the new network will fail to start. Perhaps it would be prudent to include a script to automate the genesis changes.
As written, I believe this proposals omits a change to withdraw_addr_enabled (allowing different withdraw addresses for rewards, which was originally disabled along with transfers), which I expect they intended to also re-enable along with enabling transfers. This is relatively minor and could be enabled in a later proposal - but does indicate the importance of precision.
Conclusion
I would be in favor of a revision of this proposal which served as the first indicative vote in a two-proposal process, with a second proposal slated for later to approve an exact code hash. Further feedback or discussion of the above points welcome.
5 Likes
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
1 Like
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 requires 2/3 +1 of the voting power to actually upgrade
Dev:
I feel like that won’t give sufficient time to verify the codebase
Like suppose in 2 weeks - 1 hr from now, the new release comes out, then validators have committed to upgrading in the subsequent hour
Christopher Goes:
Couldn’t there be a second proposal after the 0.34 release?
Adrian Brink:
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. - Zaki
I don’t understand the benefits of having a single person or small group have final authority over the code to run. We have the governance system for precisely this reason. What’s the benefit in weakening the security model of governance?
Zaki Manian:
I don’t actually think the security model is being weakened
because 2/3rds of the network still has to actually decide to run the code base
Christopher Goes:
Yes, that’s true
But if the height passes, the old network stops, and the new one doesn’t start that seems problematic
Dev:
You also need to ensure theres significant time for 2/3 plus one to independently verify the code
Adrian Brink:
And then the default becomes that everyone already agreed to upgrade.
Christopher Goes:
Since we would lose liveness and couldn’t vote
Maybe a default of reverting to the old network if the new one doesn’t start after 24h from the upgrade block should be built into the proposal
Adrian Brink:
Why should we possibly take the risk of having a single point of failure in the person with signing authority. I don’t see any reasonable advantage in making this part of governance.
Zaki Manian:
It’s not “part of governance” it’s part of one specific proposal
Christopher Goes:
I think because it’s faster
Dev:
To be more concrete, theres state breaking changes like this: https://github.com/cosmos/cosmos-sdk/issues/3917
that could get in, and not be labeled or voted on as well. (In this case very benign, but still)
Zaki Manian:
yeah it’s part of the milestone
Dev:
(Not labeled as state breaking change was the lack of labeling I was describing, true it was on the milestone!)
I guess I don’t see how this isn’t a reduction of security
If we establish that either way, then there is the second question of is the security trade-off / auditing trade-off (if existant) is worth it for speed
Zaki Manian:
entirely up to governance
A model of every potential code freeze point must be voted on for 2 weeks makes releasing software a very fraught endaavor
Dev:
Testnets for alternate feature sets can be started w/o governance at least
Adrian Brink:
If speed to transfers is what we wanted we could have launched with them enabled.
By having 1 person as the signing authority, governance is giving up the right to determine the default behaviour. Let’s assume that this passes, then a malicious (subtle change) commit is signed as the official version to run. Now instead of having to explicitly approve this, let’s say state change, the default is to run it unless enough people can coordinate quickly enough to try and override the default choice.
Governance is giving up an immense amount of control and placing it into a single point of failure. I really don’t see how this is different than the EOS arbitrator.
Christopher Goes:
This is only necessary for breaking upgrades. Non-breaking upgrades can be installed voluntarily.
Do you think we’ll need to upgrade frequently with such urgency that 2 wks is a problem?
Dev:
I feel like the only point where that level of urgency should be a consideration is security upgrades
Christopher Goes:
(if so maybe the solution is to shorten the voting period, although I am curious what these urgent upgrades would be)
Adrian Brink:
Plus this process of giving up huge amounts of control to a single person is a horrifying precedent to set in the first governance proposal.
Andrew @ Figment Networks:
If a second proposal goes live tmrw that is similar, but uses a specific commit hash instead, in theory could both pass?
Zaki Manian:
But how do you generate the commit hash reliably without considerable testing
Andrew @ Figment Networks:
You do the testing and it takes longer.
Adrian Brink:
Why would you generate the commit hash without considerable amount of testing, especially when activating transfers
J K:
If we give a timeout until which the code signer must approve of a hash, and 2/3 must still run it after each inspecting it, and we have plan B in case code signer fails, there’s no reliance on a central party.
Adrian Brink:
Yes, because the central signer controls the default behaviour
Zaki Manian:
yeah this is my point. Either you delegate authority on the commit hash to some key, or you end up frozen in amber on changes you might want to make to clean up docs, cli interfaces etc
Christopher Goes:
Ideally a testnet would happen first, but even starting the testnet at the same time and at least agreeing to an exact commit from the release would be progress.
Those are non-breaking changes.
Dev:
gaiacli changes should be in a different repo
Christopher Goes:
Which could be installed voluntarily without voting at all by validators who wish to.
Zaki Manian:
yeah but it still make it unclear what validators are expecting to run
Dev:
The state machine should be a standalone repository, thats a code structure problem
Adrian Brink:
Maybe the answer to this is to separate the state machine from the cli. That way we can upgrade the cli independently of the state machine and only have to vote over state machine changes
Christopher Goes:
That would help
Although there will still be many changes which change the commit hash but are non-breaking
Dev:
I mean we can run it through a comment scraper
or some of these “low effort” malleability things
Christopher Goes:
I still don’t see why this is a problem. Validators need to run the agreed-upon final state machine version commit. If they want to pull later non-breaking versions they can do so and review them independently.
Dev:
and then to audit it, you take some source, run it through comment scraper, check hashes match, then audit the commented source
J K:
Adrian, you’re pointing at a nonissue. Even plasma has a single signer that the users theoretically don’t depend on for security and industry is fine with this concept per se. the software provider is the chosen signer but isn’t relied upon. You’ll need to describe an attack, not just call it “centralization” and this is “just like EOS”. It’s not.
I admit that there may be issues, but I’m not sure they can’t mostly all be addressed in a well crafted proposal.
Adrian Brink:
I described the attack in an earlier message
Dev:
> Even plasma has a single signer that the users theoretically don’t depend on for security and industry is fine with this concept per se.
The plasma operator isn’t getting to alter the verification logic though, the verifier logic is immutable on the chain
(I think I’m missing the analogy)
Adrian Brink:
This is more like having a single signer have the ability to modify the root chain contract and say that >2/3 of miners can always choose not to run the contract
J K:
Yeah but the proposal can state that validators only run it after their own inspection.
So I did address your concern. It requires 2/3 to manually upgrade.
Adrian Brink:
Then why do you need to designate a single signer in the first place?
Zaki Manian:
yeah a proposal that describes a failed upgrade back up plan seems helpful
Dev:
You also need to allocate a sufficient amount of time for review
J K:
Why not? It narrows the realm from what is possible to a concrete actionable plan.
Yes Dev.
Adrian Brink:
My problem with this proposal is that it changes the default. It doesn’t say that everyone should inspect and then decide to run the code. It says that once the code has the correct signature you should run it
J K:
That should be in the proposal as well, it should include guarantees.
Dev:
SDK PR’s can take days to review, validators should have at minimum that much time. That ought to be codified in the proposal at minimum.
Something feels off about offloading the choice of what gets to be the state machine from governance
J K:
I think so yes.
Dev:
I feel like we’re going to get omnibus proposal issues like this
Adrian Brink:
And no one has brought an argument for the advantages of having this single signer.
Besides the time it takes to activate transfers, which if that was an issue could have just been done at launch
Zaki Manian:
it couldn’t have been done at launch
Christopher Goes:
Eh, operating the network for two weeks successfully is a lot of information.
Zaki Manian:
Launching decentralized with transfers was unsafe
Dev:
Remember the first few blocks where at 1 point someone had almost 30% of stake 
Christopher Goes:
I think we could fairly safely enable transfers now, that’s not the concern, the concern is with the safety of the upgrade process proposed.
Zaki Manian:
J K:
I think it’s fine to decide some things now, and more things later, depending on circumstances. I don’t care how we do this as long as we consider all edge cases before voting for it.
Adrian Brink:
Agreed
J K:
I still want to review some PRs too before we enable transfers. I’d like to give things another scan.
Zaki Manian:
part of the point designating a signer is that it makes the release attributable
Dev:
I’m personalyl worried about state breaking changes like these going in with unknown commits being voted upon. i.e. things like https://github.com/cosmos/cosmos-sdk/issues/3917, https://github.com/cosmos/cosmos-sdk/issues/3669 Each validator then gets a binary choice on the union of all things. (Which is the same sort of omnibus proposal we see in current polotics which causes problems)
Zaki Manian:
it doesn’t make them the governer of the network or final decision maker
J K:
I don’t recommend that we enable transfers just yet until AIB declares a commit to be the one release. That hasn’t happened yet and won’t happen until a few more things settle down, but it’ll happen very soon in a matter of 2 weeks or so.
Dev:
> it doesn’t make them the governer of the network or final decision maker
No but they get to decide the omnibus bill
J K:
And then more tests in parallel as Dev mentioned.
Christopher Goes:
At least there can be parallel proposals which remove the unwanted parts (deposits permitting).
Zaki Manian:
sure happy to help with more deposits
Dev:
how does that work out, goverrnance voting windows are fixed right?
Adrian Brink:
That sounds good and reasonable.
All I’m saying is that we should then take that commit hash and vote on it rather than delegating that authority to a single person or small group.
Christopher Goes:
(but if a single signer is approved and then an unwanted commit is included it’s unclear what would happen)
Zaki Manian:
I think outlining a fall back position in a proposal makes sense
Christopher Goes:
Yes, as soon as I see an omnibus proposal I could just make a competing one.
Adrian Brink:
It’s very clear what should happen. By default everyone is expected to run the signed and unwanted commit and it would require immense off-chain coordination in order to ensure that >2/3 don’t do it
Christopher Goes:
Current political parties effect omnibus control by controlling which bills can be voted on.
Dev:
There should be time lags on the order of days to be expected for finding an issue with an omnibus proposal
Andrew @ Figment Networks:
What I was trying to say way above is could two conflicting proposals pass nearly simultaneously. There is no multiple choice proposal type? A or B or C?
J K:
How about a first proposal for everyone to vote in favor of it from only the named software signer, if validators find it acceptable?
So the first proposal decides course of action.
Christopher Goes:
Yes they could, proposals are just text, unclear what would happen in that case.
J K:
Second solidifies the precedent of governance committing a hash which I like.
Dev:
Agreed!
Christopher Goes:
Yeah!
Dev:
That was chris’ original proposal
Adrian Brink:
What does the “named software signer” do?
J K:
Ok cool!
Christopher Goes:
That was what I suggested in the forum post.
Adrian Brink:
I agree with what Chris suggested in the forum post
Dev:
Likewise
Adrian Brink:
To be clear though, what Chris described in the forum post is different from what proposal 2 (https://stargazer.certus.one/governance/2) suggest.
Zaki Manian:
I am not generally a fan of governance commiting to githashes
J K:
Why not?
Zaki Manian:
Because i think it will be pretty natural for master to diverge from the githash in governance and it will create confusion
J K:
it’s a release revision. We need it anyways, and master isn’t as important.
I don’t trust anything but hashes.
Going to implement lamport signatures one day in Tendermint/crypto
Dev:
Nah no need for lamport sigs
just use Aurora / STARKs
(same security assumptio)
J K:
If I can understand it.
Zaki Manian:
it’s just an interesting preference trade off. Does the network prefer higher confidence on a target block height or a target commit hash?
Dev:
I don’t understand why both aren’t doable
J K:
I’m referring to a got commit hash.
Git*
Dev:
First agree to comit hash, then agree at which hieght to upgrade on
Adrian Brink:
+1
Dev:
True, they are very complicated!
Zaki Manian:
If the goal is a target commit hash, block height will be subject to a two week push back on any bug fix release
Dev:
If its non-serious I think thats okay
For security bugs, I think we need a separate process
J K:
Yeah but the second governance proposal can say x days after second proposal passing, we run hash XYZ.
Doesn’t have to be 2 weeks out necessarily. Ah you’re worried about the governance acceptance time.
Or governance decision time, and don’t want us to wait an extra 2 weeks.
Zaki Manian:
if the goal is a target blockheight, then you can do an RC1 release. Run a testnet. Run it for a week. Then do a final release at high confidence of final code
J K:
My opinion is that for things like this, esp given that it’s a second proposal, we say that the upgrade can happen as long as 2/3 approve at any time even before governance decision period has ended.
Zaki Manian:
I mean that’s interesting alternative formalism
currently no block explorers show the percentrage of staked atoms voting a certain way
so that might be a thing to try and fix
Dev:
I’m not sure thats okay to do since we want delegators to be able to override their parent validator’s votes
J K:
So delegator who aren’t quick wont have a vote, depending on the details. But I think this is fine for an upgrade as second proposal. Validators run their software and ultimately make these kinds of decisions. Delegators had chance to vote on the first proposal.
Part of the deal should be that nothing affects delegators negatively, but further details can be in the first proposal.
And any validator who think something will affect delegators negatively can vote no on the second.
But they should disagree and commit of +2/3 vote in favor of second proposal.
I’d still give a grace period of 1 or 2 or 3 days.
Dev:
Definitely feels better to do with a grace period
J K:
So +2/3 must have approved of second proposal continuously for c days.
Maybe the second proposal should have a quorum of 100%, eg 67% of all bonded stake must vote.
Maybe any upgrades require such a high degree of participation. For safety.
Dev:
At least when your voting to change the software rann
its something every full node has to do
Zaki Manian:
this is mostly about coordinating changes to block explorers to show this better
Christopher Goes:
We could integrate parts of such a process into the nodes themselves.
Warn users about pending upgrades and new software versions they don’t have, for example.
I think it would help to add more structure to the governance process in the state machine if we want to standardize this sort of two proposal process (or standardize any process)
Zaki Manian:
I am not super excited about adding a git client to gaiad
Christopher Goes:
No, that’s not what I mean
Just have a field for commit hash in the proposal directly and build the current hash into the binary (we already do this) so a warning can be displayed when they’re different
Andrew @ Figment Networks:
Looking at what’s involved with fixing this tmrw.
Jack Zampolin:
I’m pretty sure the tally endpoint gives this info
We didn’t ship with software upgrade proposals
Christopher Goes:
There isn’t a consensus spec
Jack Zampolin:
And a lot of this sounds like trying to replicate what we wanted in software upgrade proposals in a wet process
Christopher Goes:
Maybe it’s better this way actually, I think we have a better understanding of the problems now
Yes precisely - we should formalize the process
Jack Zampolin:
Well we are in the middle of the problems now
Andrew @ Figment Networks:
Jack Zampolin:
I think the question is weather or not we want to block activating transfers on formalizing a process
I think we also need to add context to the numbers (i.e. % of stake reporting, etc…)
My personal inclination would be that we should enable transfers and concurrently vote on a formal goverance procedure
Andrew @ Figment Networks:
Agree. Nothing like real proposals to elucidate the useful info
Jack Zampolin:
What do you think about that @cwgoes
Christopher Goes:
Oh I’m not suggesting that we block transfers on a hard fork for software upgrade proposals.
But rather that we simulate the two proposal process in “wet” plaintext proposals for transfers, then solidify that process in software upgrade proposals afterwards when we’re confident in it.
Dev:
I don’t see the need for software upgrade proposals
other than as a way to distinguish from the name text proposal
Christopher Goes:
More fields, maybe a separate second-proposal process and an association of the first and second proposals.
Jack Zampolin:
so that sounds like another month before that clears governace?
Christopher Goes:
An upgrade to software upgrade proposals?
Jack Zampolin:
at best
1 Like
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 have been taken. However, we believe that the enabling of transfers is a significant step in the development of any blockchain, and given that it was extensively tested before, should not be unduly delayed. This will also aid in distributing ATOM away from fundraisers and to the community, further decentralising the network’s voting power.
With regards to the changes to the genesis file, our proposal is meant to offer a direction and we expect the development team to produce the final genesis file along with the release, as has already happened on mainnet launch.
2 Likes
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.
2 Likes