gnolang / bounties Goto Github PK
View Code? Open in Web Editor NEWcosmos/gno ecosystem bounties
cosmos/gno ecosystem bounties
Hello, I have a few questions about this bounty program #7.
I think that the snapshot fork mentioned here saves the current gno state to the cosmos hub, and provides useful functions for the saved state.
Thank you!
Trying to clarify my understanding of bounty 4 with what I read from the current Gno repo, is the end goal to be able to replace the current golang parser (adapted in go2gno.go
) with this new PEG implementation?
If so, would the following overall plan look reasonable?
Step 1: have a minimalist implementation of a PEG parser in the Gno repo, this implementation doesn't have to be feature complete, mostly to get used to the coding style of the project and have something that can be moved in the right direction,
Step 2: start implementing the Gno syntax with small Gno code examples with the PEG parser (likely improve the way the initial PEG parser works in the process), have a sort of tool/small process to compare the produced AST with the one from the current go parser,
Step 3: iterate until we end up at the stage where we have a near-complete support of Gno (I guess when all examples from files/test
have a proper AST),
Step 4: rework go2gno to use the Gno parser using PEG (or alternatively, have a period during which we can switch between the two implementations until we get enough confidence the PEG approach yields correct results),
Some open questions:
I'm unsure at this stage how far I will go; I think it's important to do this incrementally, in small steps going in the right direction, so that it's useful in case other folks want to be involved. I have some experience writing BNF parsers and rules to handle ASTs for C in the past, not sure it will help here but I think I kind-of see where most of the time will be spent.
If that sounds reasonable, I'll try to come up with a clear plan for Step 1, after playing a bit more with the current codebase.
TL;DR, I think we want to start with a pure current snapshot of the account state, and apply any changes post-facto.
part 1: given a block height (the latest blockheight that you know), export the current account state. I believe there is already some feature written to export state (and side note, it probably doesn't use RPC)--used to generate the genesis.json from cosmoshub-3. Test it out at a recent block height. Check it against production data; for example, does it show the amount of tokens held in IBC channels to osmosis? Upload the snapshot to S3 or some other file storage provider.
Observation: Verified.
Proposal:
gaiad export --height will export state in json. It can be used as a genesis state to bootstrap a node.
I found an exported genesis state snapshot for Vega upgrade testnet.
curl https://github.com/cosmos/vega-test/blob/66e7ccf559998d48a5bd230a3e6146bed856a83b/exported_unmodified_genesis.json.gz
unzip ./exported_unmodified_genesis.json.gz
"genesis_time", 2019-12-11T16:11:34Z
"initial_height", 7,368,387
It was after the Delta (Gravity DEX) 13/07/21 6,910,000 cosmoshub-4 v0.34.x
find all accounts with ibc balances
jq '.app_state.bank.balances |select(.[].coins[].denom != "uatom")' exported_unmodified_genesis.json
find accounts holding OSMO tokens
jq '.app_state.bank.balances[] |select(.coins[].denom == "ibc/14F9BC3E44B8A9C1BE1FB08980FAB87034C9905EF17CF2F5008FC085218811CC")' exported_unmodified_genesis.json
The token name and denom mapping can be found here token hub
To program fancy logic, we can use gojq
https://github.com/itchyny/gojq
part 2: given an account A1 at a given block height in the past T1, and current block time T2, create a list of where all the account tokens are now, as a list of {Account;Coins} tuples. So if there were no transactions signed by A1 between T1 and T2, (and no unbondings before T1), the result would be simply [{A1;C1}] where C1 are the coins held by A1 at time T1. Implementation of this feature would start with SendTx, and then become staking aware. I don't know how best to do that off the top of my head. This also probably shouldn't use RPC but instead use go functions to iterate over blocks to avoid RPC overhead. That said, I might be wrong... if the RPC can handle say a month's worth of cosmoshub-4 blocks through localhost RPC in an hour, then it's fine. This might be feasible with unix pipes, or websockets.
Observation:
we can get current snapshot balances of all accounts from the exported state.
jq '.app_state.bank.balances |select(.[].coins | length>0)' exported_unmodified_genesis.json
OR an account's balances.
jq '.app_state.bank.balances[] |select(.address=="cosmos1z4x4dyylwym26gnsjw29hqjhkwrw6vv2p6t58k")' exported_unmodified_genesis.json
The exported state does not contain user transactions during a period of time
Same for the delegation, it has the current delegation state of each account without the delegation records.
jq '.app_state.staking.delegations' exported_unmodified_genesis.json > delegations.json
There are 171,027 accounts with balances
There are 144,197 records in the delegations
Because delegated tokens are not part of the account balance, we will need to merge these two together to calculate how many tokens each account owns.
Proposal:
We have two options
[ A ] write a program that just merges the two files in on Json that include delegation share as the additional coin in app_state.bank.balances.coins[]
Since the dataset is not huge, we merge it in memory. We can sort delegations array by delegations.delegator_address and balances array by address first. We loop through both arrays and put the result in a merged array.
The time complexity is O(N log N) for quicksort, as the address is quite random, and O(N) for merging
The space complexity is O(log N) for quicksort and O(1) for merging
PROS: simple
CONS: not flexible. we have to modify the code and get additional insights into the data set.
Joined and Merged 300,587 Accounts and 144,197 Delegations and tallied staking shares for less than 3s.
real 0m2.437s
user 0m2.085s
sys 0m0.600s
Will publish the source code soon
[ B ] dump it to two tables in postgreSQL and write the go program to query the database.
Once we dump data in postgreSQL as balances_table and delegation_table. we joined two tables, and add atoms amount and shares amount to get the total atoms that each account owns.
PROS: a lot more flexible to run SQL against the data once it is imported into the database, especially when we want to retrieve other insights from the same dataset.
CONS: complicated to set up at the beginning.
For this part of the requirement, it is the same as getting the current balance of each account.
So if there were no transactions signed by A1 between T1 and T2, (and no unbondings before T1), the result would be simply [{A1;C1}] where C1 are the coins held by A1 at time T1.
For this part of the requirement, it needs to calculate how many coins are added or removed from the account. Since the exported state file does not contains individual transactions. We can loop through send, delegation, and unbound messages from the state.db to a postgreSQL database and then query it.
given an account A1 at a given block height in the past T1, and current block time T2, create a list of where all the account tokens are now, as a list of {Account;Coins} tuples.
part 3: given a proposal, find all accounts that voted for/against/abstain, but also accounting for overrides by time (changing votes) and by delegation (overriding the validator's vote by a delegator).
Observations:
Votes from each account are not exported. Proposals only contain tallied results in the exported state file
jq '.app_state.gov.votes' exported_unmodified_genesis.json
[]
Proposal:
We can loop through vote messages from state.db to a postgreSQL database and then query it.
I've copied down the Hub1 daemon / cli / database from the ICF archives @sunnya97 shared on the Ion telegram.
My script calling the cli to get vote & deposit data is here.
I'm currently running the script for the full Ions.json but here is a sample using the first 10 or so rows from the json plus the top few Ion drop recipient addresses. This is showing a correlation of early voting, contrary to my borked script against the figment.io endpoint.
I look to add the other two hubs, but due to disk space going to have to do them one at a time. I'll be adding to my repo, which started as a script against the Osmosis daemon to find "unclaimed" ions.
We open this issue to share the development status of Adena, a native wallet for Gnoland.
Background
Current Status
Goals & Plans
Support needed
Hi! I have started working on this.
I have experience with parsing expressions from having built a symbolic math package for Julia: https://github.com/jhlq/Equations.jl
There isn't a test file for node.coffee, can someone suggest some essential tests for this component?
I’ve submitted a PR on the main repo -> gnolang/gno#119, it contains the plan and an example
Hi! I would like to claim bounty #4.
Here is my work: https://github.com/grepsuzette/joeson
port of joeson (from coffeescript/js to golang)
as literal as possible
Verbatim of the bounty (https://github.com/gnolang/bounties)
"4. Port JOESON to Go"
Hope to collaborate more but I spend so much time on this I need to publish now.
Indicate me where to communicate if you want.
I've started working on a tool that will:
Repo: https://github.com/moul/cosmos-snapshot
$> go run -v . -h
Usage of cosmos-snapshot:
-debug
verbose output
-max-height int
last block to process (default 5797010)
-min-height int
first block to process (default 5200791)
-rpc-addr string
Cosmos RPC Address (default "http://localhost:26657")
go run -v . --min-height=5200800 --max-height=5200900 --debug
go run -v . --min-height=5200800 --max-height=5200900
(without --debug
, you just get a progress bar)
Update: see my comment below for goals and updates.
we start from 24 standard words and use something very simple that only requires sha256 to generate more 256bit values: the first one is used for standard kdf & hd derivation for secp keys. The second one for alt sha256-only-kdf for ed25519 keys.
we need a sha256-only alternative to hd derivation (or possibly something like aes could work too), at the top top level, followed by some-kdf-for-privkey. Basically I would use standard hd generation but I’m trying to only trust sha256 for important stuff, not sha512.
we should first start with a goal document, then a proposed plan document, get it reviewed, before implementation.
I've manually researched about 40 address on Mintscan (including the biggest receivers of the airdrop)
I found a match on
Hello, Sam Wang said to correspond on this github page. Was looking for clarity on what exact contracts you are looking for a retrospective on / or if you are looking for someone to audit their contracts? I work at Moultrie Audits so this seems within our wheel house.
The 1000 osmo bounty is straightforward.
The 5000 osmo distribution needs a summary with amounts and osmo addresses,
and justification with links to all work.
The person who puts together such a document ought to be paid too.
I'll add 500 osmo in addition for anyone who proposes the winning summary of distributions.
bounty distributions should pay out some to notable contributions, but most of the bounty must go to those who completed the objectives; and moreso for extra work that makes the work/data/code usable for more use-cases. Figuring out the original hidden distribution of ION accounts is outside the scope of the bounty, but should be accounted for, but not at the expense of work/data/code generalization.
The ulterior point is to create a streamlined pipeline for bounty rewarding.
We can design processes outside of the blockchain, and code them in later.
This repository summarizes the Interchain Foundation's approach to delegating its ATOMs.
https://github.com/interchainio/delegation
ICF funding reports 2018-2019
https://github.com/interchainio/funding/tree/master/projects
ICF Delegations till 4/2020
https://github.com/interchainio/delegation/tree/master/delegations
Original Cosmosplan by Cosmos whitepaper
https://github.com/cosmos/cosmos/blob/master/PLAN.md
scraped data and scripts of cosmos-hub 1-4 gov module
I made another version of ed25519 implementation here in this repo: https://github.com/nghuyenthevinh2000/bounty5
Extra data to support the manual research and proving the relation between staking at Sikka and voting
Electric capital has identified and updated here data about all the active crypto ecosystems:
https://github.com/electric-capital/crypto-ecosystems/tree/master/data/ecosystems
what I'll do:
this should be a simple loop through gaia4's data with some custom logic
I made some modification in gnolang to implement ed25519 key. Details in this repo
https://github.com/romelukaku/Bounty5
The option set of a proposal refers to the set of choices a participant can choose from when casting its vote.
The initial option set includes the following options:
Yes
No
NoWithVeto
Abstain
*NoWithVeto counts as No but also adds a Veto vote. Abstain option allows voters to signal that they do not intend to vote in favor or against the proposal but accept the result of the vote.
Quorum
Quorum is defined as the minimum percentage of voting power that needs to be casted on a proposal for the result to be valid.
Threshold
Threshold is defined as the minimum proportion of Yes votes (excluding Abstain votes) for the proposal to be accepted.
Initially, the threshold is set at 50% of Yes votes, excluding Abstain votes. A possibility to veto exists if more than 1/3rd of all votes are NoWithVeto votes. Note, both of these values are derived from the TallyParams on-chain parameter, which is modifiable by governance. This means that proposals are accepted iff:
There exist bonded tokens.
Quorum has been achieved.
The proportion of Abstain votes is inferior to 1/1.
The proportion of NoWithVeto votes is inferior to 1/3, including Abstain votes.
The proportion of Yes votes, excluding Abstain votes, at the end of the voting period is superior to 1/2.
If the delegator votes before its validator, it will not inherit from the validator's vote.
If the delegator votes after its validator, it will override its validator vote with its own. If the proposal is urgent, it is possible that the vote will close before delegators have a chance to react and override their validator's vote. This is not a problem, as proposals require more than 2/3rd of the total voting power to pass before the end of the voting period. Because as little as 1/3 + 1 validation power could collude to censor transactions, non-collusion is already assumed for ranges exceeding this threshold.
Source: https://docs.cosmos.network/master/modules/gov/01_concepts.html#vote
An air-gapped computer is often heralded as an impervious defense to an online attack, but is that really true? Is there some way that a hacker from outside can infiltrate an air-gapped network? All cold wallets need some means of connecting to the network to execute transactions or download operating system or wallet software. With air-gapped computers, data transmission usually happens by USB.
Possible scenarios:
A virus infiltrates the air-gapped computer, most commonly through infected USB.
The virus takes control and sends instructions to a specific component of the computer
The virus leverages its control over the component to exfiltrate (export) the private keys
Side channel attacks
Not common but possible:
-Virus takes control of the computer fan to exfiltrate information through sound
-Virus manipulates hard disk drive noise to exfiltrate information
-Virus causes the air-gapped computer to output radio signals generated by the computer’s electromagnetism
-And in the most alarming example, a virus was even able to use ultrasonic waves to output the private key information stored on an air-gapped computers and air-gapped Raspberry Pis
The dangers to air-gapped computers don’t stop there for users of third-party operating system or wallet software. In an example of how even software downloaded from trusted official pages can carry its own risk, hackers in 2016 replaced the official Linux Mint download icon with their own backdoor program. Just as this malware link affected everyone who clicked where it was inserted on the Linux Mint download page, a virus can infiltrate an air-gapped computer in the form of “trusted” software.
Android Devices as Cold Wallets:
Above pointed out the various reasons why offline computers cannot be considered truly air-gapped. But what about smartphones, which have no fans or mechanical hard drives?
Let’s first take a look at Android phones. Android phones rely on TrustZone for security (Let’s take it for granted that private keys are actually being stored in TrustZone, although there have been known to be incidents where unscrupulous vendors weren’t doing so). Demonstrations of leaking private keys through side-channel attacks show that TrustZone can be quite vulnerable. This means that if an attacker gains physical access to an air-gapped Android, they can steal its private keys through complex but practically achievable methods. Android chip manufacturers can release patches once zero-day attacks are discovered, but Android device makers then need to pass them on to users, which they sometimes don’t agree to do.
iPhones as Cold Wallets:
iPhones use something called the Secure Enclave, which can be understood as a Secure Element embedded in the main processor. As the likeness in name suggests, Apple’s Secure Enclave pioneered the use of Secure Elements in smartphones. The Secure Enclave is capable of performing pretty much every function of a Secure Element including true random number generation (TRGN) and even shares most of its physical properties
Despite what the Secure Enclave is capable of, it’s completely useless for cryptocurrencies because Apple has total custodianship of the private keys and does not open their use up to any other party. Not only is Secure Enclave based on secp256r1 elliptic curve encryption while Bitcoin uses secp256k1, but even if Secure Enclave supported secp256k1, Apple doesn’t provide an API for extracting private keys or the recovery seed
Because you cannot use the Secure Enclave for anything other than Apple ecosystem functions, you need a third-party app to use an iPhone as a cold wallet. The fact that transaction signing and private key storage then have to happen on the iOS level and not within the Secure Element represents an incomparable difference in terms of security. Private keys stored on the iOS level are an easier target for the side-channel attacks described above as possible on TrustZone. Furthermore, as all random number generation on wallet apps is algorithm-based, you’ll end up with a pseudorandom rather than true random number for your recovery seed
While an iPhone has a smaller attack surface than a computer and does not use USB data transmissions, it isn’t much safer because Secure Enclave can’t perform transaction signing and private key storage in a secure environment or TRGN in a way that is recoverable. Even if Apple were to add support for secp256k1, you would not be able to backup your wallet if anything happened to the iPhone. Neither will Apple’s release of CryptoKit signify a change for cold storage.
Sum-up:
Hardware wallets are minimalistic devices with drastically reduced attack surfaces. While air-gapped smartphones are somewhat safer than air-gapped computers, don’t be lulled into a false sense of security by the tradition of using either. If you’re truly interested in securing your assets, you should only be looking at hardware wallets with a Secure Element.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.