annotated-spec
EIPs
annotated-spec | EIPs | |
---|---|---|
44 | 486 | |
312 | 12,525 | |
0.0% | 0.5% | |
0.0 | 9.8 | |
2 months ago | 7 days ago | |
Python | ||
- | Creative Commons Zero v1.0 Universal |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
annotated-spec
- Daily General Discussion - February 17, 2023
-
Can't the Sync Committee be cheaply bribed, and therefor serves no real purpose for security?
My current understanding: The Sync Committee selects 512 validators to continually sign off on block header. Any block headers that get >2/3 are "valid"1, such that Light Clients using this header for verification can trust it.
-
Ethereum Mainnet Merge Announcement
https://github.com/ethereum/annotated-spec/blob/master/phase...
Here we have slashing fields in the block body where you insert your proofs of slashable offense. There are functions with a “slash” in the name that describes precise state transition.
The hard part of slashing is finding these proofs because you have to do more work than necessary to detect slashing and produce proofs - that’s what this software does. It’s more expensive to run a slasher but you need only one and it does not matter who runs it, anyone can run it. The link that you sent says that this slasher broadcasts proofs by default - that way anyone can include it.
-
Explaining Ethereum's consensus mechanism after The Merge
According to Eth docs:
> One validator is randomly selected to be a block proposer in every slot. This validator is responsible for creating a new block and sending it out to other nodes on the network. Also in every slot, a committee of validators is randomly chosen, whose votes are used to determine the validity of the block being proposed.
The annotated code for this can be found in [2].
[1] https://github.com/ethereum/annotated-spec/blob/master/phase...
[2] https://notes.ethereum.org/@vbuterin/Sys3GLJbD#Misc
-
Daily staking income was irregularly high, anyone knows why?
Here's some more info on Sync committees if you are interested. https://github.com/ethereum/annotated-spec/blob/master/altair/sync-protocol.md
- Daily General Discussion - February 20, 2022
-
My First Impressions of Web3
The crux of the article is that the front-ends are all routing calls through centralized APIs to get their message included on the blockchain. Infura and Alchemy don't do much. They just pass a JSON-RPC message to an Ethereum node running on their servers. There is some additional indexing services they provide, but there are many open, decentralized alternatives for that such as TheGraph Protocol. And it's not unfeasible for an application to run its own Postgres instance to index data from the ETH blockchain.
As for full-fat clients on normal mobile devices, the main issue is the data requirements. Running a full node can take hundreds of gigabytes. It is possible on light hardware. People are running Beacon chain nodes on Raspberry Pis. But you do need the storage and that tends to be scarce on mobile.
Meanwhile, the Ethereum core devs are aware of this issue and are actively working towards it. They shipped the Altair hard fork this year that has adds sync committees which make it possible to do without needing the whole chain history (using merkle trees): https://github.com/ethereum/annotated-spec/blob/master/altai...
The light client to follow from those improvements is forthcoming:
-
ETH2.0 withdrawal roadmap post merge
It's not about validators going offline, it's about the validator set changing. To quote the annotated specs
-
Proof of stake is a scam and the people promoting it are scammers
Even a relatively light reading of the Annotated Spec[1] for Eth2 and/or the Eth Org's Proof of Stake FAQs[2] suggests the designers (and independent implementer-teams who gave feedback to designers... lather, rinse, repeat) understand it's important to consider the overall system "outside of the comfort zone".
[1] https://github.com/ethereum/annotated-spec/blob/master/phase...
[2] https://eth.wiki/en/concepts/proof-of-stake-faqs
-
Help understanding staking factors
Alpha leak: I am currently finishing up a full revision of my annotated specification for Altair, and plan to get it published in a couple of weeks. Meanwhile Vitalik's annotated spec has some info on how base rewards work under Altair.
EIPs
-
Ethereum Foundation removes their canary
Even more relevant would be the Ethereum Improvement Proposal repo (where people submit proposals to change the spec):
https://github.com/ethereum/EIPs
Or the go-ethereum execution client (the most popular execution client):
https://github.com/ethereum/go-ethereum
-
Bridging the Gap: Better Token Standards for Cross-chain Assets
It’s early in the life of the xERC20 standard, but progress is quickly being made. The standard has been audited and is already live with a few projects. The EIP to adopt the standard has been created, and implementation has begun. Alchemix recently announced support for the xERC20 standard. And Defi Wonderland has published a suggested implementation on their GitHub. This implementation has an interface for the xERC20 contract with eight core functions that the token issuer must implement. These are functions related to setting the Lockbox contract (setLockbox), issuance limits for bridges (setLimits, mintingMaxLimitOf, burningMaxLimitOf, etc.), and the core mint and burn functions.
-
Numbers Protocol submitted EIP-7517, Allowing Consent for AI Data Mining on the Blockchain
Check out EIP-7517: Giving Consent for AI Data Mining on the Blockchain
-
Exploring ERC20 Tokens: The Powerhouse Behind Ethereum's Tokenized World4
ERC223 is not widely implemented, and there is some debate in the ERC discussion thread about backward compatibility and trade-offs between implementing changes at the contract interface level versus the user interface.
- EIPs/.github/workflows/post-ci.yml at master · ethereum/EIPs
- EIPs/.github/workflows/ci.yml at master · ethereum/EIPs
-
Process of recalculating the transactionRoot from a block transaction hash
Ethereum Improvement Proposals (EIPs): These are proposals to change various aspects of Ethereum. They often contain detailed technical discussion and can be a good resource for understanding the finer points of how Ethereum works. EIPs can be found here: https://eips.ethereum.org/
-
Burning ETH is great for the price, but may be a risk to decentralization (A critique of the ETH burn model and a recommendation for new economics)
Worth looking at: EIP6968: Contract Secured Revenue on an EVM based L2 https://github.com/ethereum/EIPs/pull/6969/files
-
Calling All Devs and Crypto Enthusiasts: A Community-Driven Anti-Scam Registry on the Blockchain
Additionally, I have made an EIP that can help standardise and maintain official contract registry of each DApp. This can help identify official contracts of a protocol vs scammers using fraud contracts but presenting like official protocol. https://github.com/ethereum/EIPs/pull/6807
What are some alternatives?
ethmerge.com-content - Markdown formatted content for the ethmerge.com website.
bips - Bitcoin Improvement Proposals
consensus-specs - Ethereum Proof-of-Stake Consensus Specifications
openzeppelin-contracts - OpenZeppelin Contracts is a library for secure smart contract development.
pm - Project Management: Meeting notes and agenda items
token-allowance-checker - Control ERC20 token approvals
ens - Implementations for ENS core functionality: The registry, registrars, and public resolvers.
avalanche-wallet - The Avalanche web wallet
crypto-fees - Website for comparing total daily fees of various blockchain protocols.
rocketpool - Decentralised Ethereum Liquid Staking Protocol.
beigepaper - Rewrite of the Yellowpaper in non-Yellowpaper syntax.
solidity - Solidity, the Smart Contract Programming Language