Borrowed from Osmosis's contribution guidelines
Any contribution that you make to this repository will be under the Apache 2 License, as dictated by that license:
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
Contributors must sign-off each commit by adding a Signed-off-by: ...
line to commit messages to certify that they have the right to submit
the code they are contributing to the project according to the
Developer Certificate of Origin (DCO).
When updating global parameters, you must update the following files:
For x/emissions
:
x/emissions/types/params.go
- Set the default values for the new params
- Add a new function to return the default values
- Add validation for the new params
x/emissions/proto/emissions/v1/params.proto
- Add to the
Params
proto, tracking all global params
- Add to the
- x/emissions/proto/emissions/v1/tx.proto
- Add to the proto of the tx that allows us to set new params
x/emissions/keeper/msgserver/msg_server_params.go
- Add code to the tx that allows us to set new params
- Update any tests where all params need to be specified
- Update any external docs here:
For x/mint
:
TBD
When updating the state machine, you must update the following files:
x/emissions/keeper/keeper.go
x/emissions/keeper/keeper_test.go
as neededx/emissions/types/keys.go
x/emissions/keeper/genesis.go
x/emissions/keeper/genesis_test.go
x/emissions/proto/emissions/v1/genesis.proto
It is critical to avoid performing network requests to external services since it is common for services to be unavailable or rate-limit.
Imagine a service that returns exchange rates when clients query its HTTP endpoint. This service might experience downtime or be restricted in some geographical areas.
As a result, nodes may get diverging responses where some get successful responses while others errors, leading to state breakage.
Randomness cannot be used in the state machine, as the state machine definitionally must be deterministic. Any time you'd consider using it, instead seed a CSPRNG off of some seed.
One thing to note is that in golang, iteration order over maps is non-deterministic, so to be deterministic you must gather the keys, and sort them all prior to iterating over all values.
Threads and Goroutines might preempt differently in different hardware. Therefore, they should be avoided for the sake of determinism. Additionally, it is hard to predict when the multi-threaded state can be updated.
This is out of the developer's control but is mentioned for completeness.