Releases: allora-network/allora-chain
Releases · allora-network/allora-chain
v0.4.0-release-RC
add online, weak merit based sortition without new scores yet (#568) <!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺ v ✰ Thanks for creating a PR! You're awesome! ✰ v Please note that maintainers will only review those PRs with a completed PR template. ☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --> ## Purpose of Changes and their Description ### Why "Weak"? @jmdkastro formulated a well-defined theory of merit-based sortition plus simulation. This rhymes with that, but is not exactly that. A consequence of https://github.com/allora-network/allora-chain/pull/567 will be way greater stagnation in the active set, as those with scores have an actual opportunity to make it into their topic's epochs. Hence, there is a need to quickly add a non-corrosive form of permeability to the network. This route maximizes our ability to serve large cohorts of workers while enabling for more sophisticated methods later, potentially as fast-follows. ### How it Works #### Definition * **Active set** = Your inference/forecast/reputer loss payload is considered as part of rewards/inference synthesis calculations * **Passive set** = Your inference/forecast/reputer loss payload is not considered as part of rewards/inference synthesis calculations We differentiate between these 2 sets because calculations for the active set are expensive => this must be bounded. However, we must cycle through participants, so we now need a name for those "passively considered" actors. #### When scores are calculated in rewards * An EMA score is updated for each actor of each type * A topic-defined quantile of the active set is taken for each actor type (inferer, forecaster, reputer) * This will be used in the next epoch * For example if EMA score among active set is [10,20,30] then topic quantile might be 12 (linear interpolation) #### In the next epoch * We skim the top in an online fashion i.e. * If we have not yet met our limit per actor type per epoch, then we add the actor payload to the active set * If we have met our limit per actor, then we ask if the EMA score of the new actor is better than the lowest in the current active set. * If yes, then we pop the lowest scorer by EMA score out of the active set and update their EMA using the topic quantile of the previous epoch * If no, then we update the EMA score of the rejected actor using the topic quantile of the previous epoch In summary, if you're in the active set, your EMA score gets updated based on your performance in this round, and if you're int he passive set, your EMA score gets updated based on the performance of the previous epoch's active set. In either case, we do calculations in an online fashion => the true limit of actors for which we can do calculations is the cumulative blockspace within a worker submission window. ## Link(s) to Ticket(s) or Issue(s) resolved by this PR ## Are these changes tested and documented? - [ ] If tested, please describe how. If not, why tests are not needed. - [ ] If documented, please describe where. If not, describe why docs are not needed. - [ ] Added to `Unreleased` section of `CHANGELOG.md`? ## Still Left Todo * Fix tests * Add more coverage --------- Co-authored-by: michael <[email protected]> Co-authored-by: Tyler <[email protected]> Co-authored-by: T <[email protected]> Co-authored-by: Guilherme Brandão <[email protected]>
v0.4.0-RC
Ema the scores 2 (#560) <!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺ v ✰ Thanks for creating a PR! You're awesome! ✰ v Please note that maintainers will only review those PRs with a completed PR template. ☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --> ## Purpose of Changes and their Description ## Link(s) to Ticket(s) or Issue(s) resolved by this PR ## Are these changes tested and documented? - [ ] If tested, please describe how. If not, why tests are not needed. - [ ] If documented, please describe where. If not, describe why docs are not needed. - [ ] Added to `Unreleased` section of `CHANGELOG.md`? ## Still Left Todo *Fill this out if this is a Draft PR so others can help.* --------- Co-authored-by: Tyler <[email protected]>
v0.3.1-upgrade-test
Remove duplicated import
v0.3.1-devnet-upgrade-test
Remove duplicated import
v0.3.1
Hot fix: Ensuring worker presence between reputer reports (#562) One of the properties of the reputer bundle was not being considered in this function, causing a chain halt!
latest
Release v0.4.0 2 dev (#565) <!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺ v ✰ Thanks for creating a PR! You're awesome! ✰ v Please note that maintainers will only review those PRs with a completed PR template. ☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --> ## Purpose of Changes and their Description ## Link(s) to Ticket(s) or Issue(s) resolved by this PR ## Are these changes tested and documented? - [ ] If tested, please describe how. If not, why tests are not needed. - [ ] If documented, please describe where. If not, describe why docs are not needed. - [ ] Added to `Unreleased` section of `CHANGELOG.md`? ## Still Left Todo *Fill this out if this is a Draft PR so others can help.* --------- Signed-off-by: Guilherme Brandão <[email protected]> Co-authored-by: Guilherme Brandão <[email protected]> Co-authored-by: Guilherme Brandão <[email protected]> Co-authored-by: Diego C <[email protected]>
hotfix-v0.3.1
Hot fix: Ensuring worker presence between reputer reports (#562) One of the properties of the reputer bundle was not being considered in this function, causing a chain halt!
v0.3.0
Added
- Changelog added (this), improved contribution guidelines, and simplified PR template
- #443 Create mechanism to import and export state with
initGenesisandexportGenesis - #461 Create index of topics by block height at which their open worker nonce closes
- #432 State sync enabled for faster validator syncing
- #478 Create and apply abstraction for augmenting topic fee revenue that is sure to check for topic activation criteria for both funding events, fee payments, and stake additions
- #482 Creation of an official Upgrade Flow
Removed
- #458 Removal of Blockless and batch processing; Introduction of online, individual payload processing. This resolves many security, performance, and scalability issues.
- A number of PRs were merged prior to v0.3.0 that improved upon our usage of Blockless, however that has been removed in favor of its removal in #458. Hence, we are not listing those PRs here.
- #462 Add individual payload processing
- #470 Skim of top performers per topic as they submit payloads ("online skimming")
- #464 Remove libp2p peer ids from chain
- #459 Revamp nonce management
Fixed
- #486 Correctly set initial emission per unit staked token
- #460 Apply a number of bugfixes and high-precision unit tests that ensure our implementation matches our simulation of Allora and therefore the original intentions of the whitepaper and Foundation.
- #487 Patch to have the single
alloradhome folder in Docker - #437 Fix issue for excessive effective revenue dripping
- #441 Prevent DoS from attempting to withdraw negative stake amounts
- #472 Prevent topics to be created with a ground truth lag too big so that the reputation nonce could be dropped when the ground truth is revealed
- #484 Fix issue with permissions within Docker container
- #477 Fix issue arising from no forecasts being sent in worker payload
- #436 Fix bug related to excessive usage of topic ground truth lag and misleading error message
- Additional bugfixes and improvements
Security
v0.3.0-upgrade
fix the manual insert of upgrade binary
v-offchain-1
tagging removing b7s