Diegorb1329/eth_magicians_forum huggingface dataset:
Title: Sustained_bandwidth_as_a_L1_resource___ETH_s_shard
Category: Magicians

Author: realty
Date: 2022-04-22T18:00:12.037Z

Several EIPs (e.g. 4488, 4844) have been proposed which advocate for increasing avg block size by up to an order of magnitude while mitigating state growth through new data retention requirements.
Additionally this slide is making the rounds which considers burst, but not sustained, bandwidth as a limiting resource.
media_FQ4CJpPVsAA7iVa.jpg?name=small680×364 30.2 KB
Setting aside burst bandwidth limits, the community and the proposers of the above and similar EIPs need to have a discussion on what the acceptable limits are for the data usage of the network.
Current monthly data usage for a user running a CL/EL client pair is in the low single terabyte range.
If something like EIP-4844 is introduced (which proposes economics incentivizing 1mb avg blocks vs ~100kb now) , we could easily see data usage reach 20+ TB per month.
Is this a number that the community is comfortable with?  How many personally run nodes/validators will be forced/incentivized to transfer to AWS or a staking pool?  How do we balance those costs vs. the gains (L2 fee reduction)?
Title: Web3Authn_idea___use_webauthn_as_a_web3_wallet
Category: Magicians

Author: vorcigernix
Date: 2022-12-04T12:00:33.858Z

I accidentally discovered the WebAuthn protocol and I can’t stop wondering why we don’t use the standard, browser supported solution instead of wallets. There is an alternative description of how webauthn works. There are two things that need to be solved on top of an existing protocol to serve the web3 use case. First is accepting a transaction, my idea in a picture attached is that every transaction would cause re-authentication and as an app developer you will be responsible to explain what the user is signing. I understand that this could be problematic from the security perspective, but I’d argue that most people sign the gibberish anyway and the current solution is wrong anyway.
Second problem to solve is that the registration is scoped. I propose to have a simple federation server (could be ENS) that will serve as a registry, redirecting the authentication to the server where the user is registered. This is an MVP version, later we can figure out some sync mechanism - after all the private key stays on the client device, so the registration is not really security sensitive (IMO).
Please see the (super simplified) illustration that can make my idea more clear.
web3authn4690×3652 231 KB

Author: vorcigernix
Date: 2022-12-04T16:01:21.991Z

One thing to add, problem #3: There is no recovery key or anything like that. I have no idea how to solve it, webauthn is designed in a way that kind of removes our ability to reverse create a recovery from the private key or something like that. Maybe something like a weak multisig like smart contract can help, but my level of expertise is limiting my thoughts in the area. Will dig deeper though.

Author: vaumoney
Date: 2022-12-05T19:40:44.325Z

isn’t --nat=extip critically-necessary for a proper content-security allow-list (i.e. to allow _mint by RLP)? I think Authority by consensus can be useful for a forgot pass minter, but I don’t think much else tbf.
Title: Gas_Subsidy_for_low_gas_transactions
Category: Magicians

Author: MaestroKongrio
Date: 2021-03-18T21:02:47.923Z

An idea come to my mind, and I was instructed to discuss here before proceed with EIP or such stuff… maybe someone has the same idea before…
It’s no secret that gas cost are making Ethereum a network for riches and whales. With fees over USD 10 for just an Ether transfer, network is becoming unpayable for many users. It’s always possible to send a low gas price tx and wait until network process it, but right now you can wait almost forever and your tx may not be processed.
Like governments collect taxes from riches to help poors (in theory), my idea is to collect some sort of tax from higher gas price transactions, to help fund lower gas prices ones. The idea isn’t fully ready, but the main points are:

We know whats the gas price for every transaction in a block. So, we can apply a certain tax to the higher gas price txs. Just as an example, lets says we tax the 20% higher prices tx with a 10% fee. Let’s call this “the poor people gas pool”
The miner who process the block, add a new item to it: a hash of the content of his mempool of pending txs (Merkle Trees already solve this issue).
To get funds from the pool, a user can make a request. A score can be computed from the gas cost and how many blocks away from the original submisssion is the tx (with the hash, this can be easily verified), so the user can get funds from the fund to help him pay for his transactions using funds from high paying whales.

The main benefits is that the Ethereum network will be a real alternative for low price transactions willing to wait a long time. Right now, low gas price txs are never processed.
I’m not a protocol expert, but I realize this is a big change, because it required to change the block structure, and it will require some several  wallets mods to make this usable.
Anyone think this is a viable idea?

Author: esaulpaugh
Date: 2021-03-19T02:12:58.864Z

Adding more computation to the protocol is a tax on the network as a whole. Also, this would end up being a tax on privacy since privacy-preserving transactions are high-gas. And no taxation without representation.
Title: Request_new_Rings___Categories_by_filing_an_issue
Category: Magicians

Author: boris
Date: 2018-07-23T12:16:50.104Z

As people are creating new Rings, we’re getting questions on how to create sub categories under #working-groups or other forum stuff.
Please file an issue for this https://github.com/ethereum-magicians/scrolls/issues for now – @jpitts is the only one with permission at the moment, but if we start using issues this will I think help us scale that, as well as give a record of changes.
You can feel free to post here in #site-feedback for broader discussion of issues too.
Title: MathTeX_in_EIPs
Category: Magicians

Author: fulldecent
Date: 2019-03-24T18:02:47.396Z

GitHub pages has partial support for using MathTeX in GitHub pages (which is the mechanism used to publish EIPs to eips.ethereum.org).
We can fix it so that these expressions will render properly in the browser.
Issue: https://github.com/ethereum/EIPs/issues/1860
MathTeX just lets you put math TeX expressions inline in a paragraph or as their own expression block. If you’ve used TeX it looks like this:
$$y = \sqrt(x)$$
and it renders perfectly just like in every math book you have ever read. That is because every math book you have ever read uses TeX.

Author: boris
Date: 2019-03-24T18:46:05.020Z

I left a comment on the issue. It may be simpler than that.
Let’s see if this is turned on in Discourse. Edit: nope!
Anyway, should be pretty simple to do.

$$
\begin{align*}
& \phi(x,y) = \phi \left(\sum_{i=1}^n x_ie_i, \sum_{j=1}^n y_je_j \right)
= \sum_{i=1}^n \sum_{j=1}^n x_i y_j \phi(e_i, e_j) = \
& (x_1, \ldots, x_n) \left( \begin{array}{ccc}
\phi(e_1, e_1) & \cdots & \phi(e_1, e_n) \
\vdots & \ddots & \vdots \
\phi(e_n, e_1) & \cdots & \phi(e_n, e_n)
\end{array} \right)
\left( \begin{array}{c}
y_1 \
\vdots \
y_n
\end{array} \right)
\end{align*}
$$
Title: Distributed_Accomplishable_Intents
Category: Magicians

Author: michaeldunwort1
Date: 2021-10-06T03:41:58.416Z

I’m a new user so limited on the content/links I can post, but you can find the unedited version here
 Distributed Accomplishable Intents 
tl;dr - We’re should aim to turn the address bar into a search engine. Encoding the function calls and search terms for desired outcome into a natural language system.

Can I borrow your brain for a second? I need you to try and wipe the idea of the address bar as a way to send and receive assets. Pasting in the janky addresses. Going through triple checking a bunch a characters to make sure they’re correct, then finally pulling the trigger and clicking confirm.
In fintech these are referred to as “payment intents” where we have a finite path that user can go down to checkout. Sort of how you present different fields based on what payment method you choose, it’s like a pre-defined path to collect the necessary information as seamlessly as possible to complete your checkout.
An example for crypto would be with MakerDAO. “Deposit collateral and generate DAI”. Because it’s a common use-case, a pre-defined intent of users opening CDP’s it means that we can build a one click behaviour.
It’s a common theme, and will only trend more and more toward repeated value adding intents.
Think of it more as a way to “communicate” your goals and intentions of your payment to a distributed system.
Example Language

“Deposit.ToSavings.eth” (this deposits into compound, and returns CUSDC)
“dai.toBitcoin.eth” (converts DAI to WBTC as outlined in the example above)

If you are looking for a simple mental model think of it this way…
New users get something like an Amazon 1 click checkout for Ethereum smart contract interactions.
New users get a familiar “Google” like interface UX/UI flow.
Title: Donations_to_the_Un_organisation_of_Ethereum_Magic
Category: Magicians

Author: Ethernian
Date: 2018-10-30T19:08:27.033Z

Hello, all!
Even I was not able to take part in Meta-Magicians and EIP & Interoperability Discussions, I have listened to it some minutes. As far I could understand, the is an opinion, we need some kind of organization in order to accept donations given to Ethereum Magicians.
I am a big supporter of an idea of personal membership and would avoid any formal organization so much as possible. Money and payments will make the organization even more problematic in my eyes.
So I would make a proposal how to accept donations without becoming an organization at all.
If would introduce magicians token (MEM - Magic Ethereum Mana?   ), which should be publicly tradeable. The token could be minted for people for their activities inside FEM. Donators targeting the community as whole should not pay to FEM directly, they should buy and burn some amount of tokens and present an proof-of-burn. FEM can publicly maintain of the list of the biggest burners (sponsors). Buy and Burn actions will create a price for the token.
May be, we could introduce sub-tokens for particular Rings for the case if the sponsor would like to support particular Ring (f.e. MEM.Wallet). In this case a he could buy and burn a mix of MEM token and MEM.Wallet token in some proportion.
This is a rough idea. Many aspects have to be defined yet. Nevertheless it solves the main problem: we don’t need a organization to accept donations.
@boris, I hope the idea could be valuable for your talk tomorrow.

Author: boris
Date: 2018-10-30T20:04:47.211Z

Thanks for your thoughts!
There are notes and I need to start a thread here to further summarize.
We didn’t really talk about needing an organization.
There is a problem we identified where sending an invoice and receiving fiat on behalf of FEM or a ring (shared by myself and @fubuloubu) AND dealing with the associated taxes.
This is (partially) solved with Host Organizations.
The other problem is governance of the funds.
I’ll write more in the follow up notes.

Author: Ethernian
Date: 2018-10-30T22:56:50.375Z

boris:

The other problem is governance of the funds.


in my model nobody holds FEM’s funds because there is no any. But most are holding own FEM token, which becomes valuable as result of FEM activities.

Author: boris
Date: 2018-10-31T00:35:53.078Z

Then it’s governance of those tokens. Anyway – not actually a problem that we raised. We do need to continue the discussion of which problems someone wants to tackle.
We can’t get around governance of funds – aka what do decide to spend the funds on. This will be more clear when I share the notes.

Author: Ethernian
Date: 2018-10-31T20:02:06.597Z

boris:

Then it’s governance of those tokens…


governance of everybody’s own token is not an problem of Magicians as organization. My point was more about preventing organization holding any funds. But the challenge of funds governance AKA spending funds (even privately held) remains.



 boris:

This will be more clear when I share the notes.


will move for discussion there.
Title: Overwhelmed_by_number_of_EIPs__ERCs__etc____Better
Category: Magicians

Author: Ethernian
Date: 2018-08-07T12:21:06.767Z

Hello all!
Am I only the guy, who is totally overwhelmed by new EIPs, ERCs, and other proposals?
I don’t want to miss something important, but currently reading tons of EIPs that look like a DesignPattern, but not a Standard change or proposal.
A Standard  requires a community’s formal acceptance and release, but DesignPattern do not.
I think we are missing a tag signalling what the EIP’s Author is looking for. Is he looking for discussion? Is he looking for formal acceptance or consensus?
I am open for better ideas, but I would definitely play down the number of EIPs we have - many of them are not EIPs at all.

Author: ligi
Date: 2018-08-07T13:33:00.194Z

No - I have the same problem. I had an idea once that might help to mitigate the problem a bit: https://github.com/ethereum/EIPs/issues/896 - it got some positive words - but never real traction. Also I am not sure how to roll this out. Perhaps a second attempt is needed as the pain is now even bigger? Ideas very welcome - I am still a big fan of the idea of splitting it. Not only for better structure - also because this EIP<>ERC thing really sucks in my eyes - sometimes you read ERC- - sometimes EIP-55 - clear naming and structure would be so nice also for this.

Author: Ethernian
Date: 2018-08-07T16:00:59.546Z

// PRELIMINARY THOUGHTS
hmm… I think we should discuss in depth about it. Currently, I am not convinced, because your naming pattern looks like too narrow to me. There are proposals, that will fall in many different categories at the same time. This shouldn’t reflected by name, it should be reflected by tag (multiple tags).
The EIP naming has only two goals:

to refer the proposal
to signal, that this proposal SHOULD be reviewed by whole community.

IMHO, everything that should not be discussed by whole community, should not be an EIP (but can be other xIP).
hmm… what about influencing groups and the “strange loop”? this could be a way to structure the EIP discussion…

Author: AtLeastSignificant
Date: 2018-08-08T14:27:44.966Z

Just posting for prosperity:
https://www.reddit.com/r/ethereum/comments/95bnxx/overwhelmed_by_number_of_eips_ercs_etc_better/
Title: Solidity_Optimizer_and_ABIEncoderV2_Bug
Category: Magicians

Author: jpitts
Date: 2019-04-01T07:01:04.190Z

Through the Ethereum bug bounty program, we received a report about a flaw within the new experimental ABI encoder (referred to as ABIEncoderV2). Upon investigation, it was found that the component suffers from a few different variations of the same type. The first part of this announcement explains this bug in detail.
Additionally, two low-impact bugs in the optimizer have been identified over the past two weeks, one of which was fixed with Solidity v0.5.6. Both were introduced with version 0.5.5. See the second part of this announcement for details.

From the Ethereum Foundation blog:



Ethereum Foundation Blog



Solidity Optimizer and ABIEncoderV2 Bug | Ethereum Foundation Blog
Title: PoC_for_Recurring_Payments_on_Ethereum
Category: Magicians

Author: Jon-Becker
Date: 2021-10-27T18:12:32.291Z

twitter.com


Jonathan Becker
@BeckerrJon

  ⚙️ Ethereum-Recurring-Payments 1.0.0

A PoC for Recurring Payments on Ethereum using ERC20's approve and transferFrom methods.

Repository:
https://t.co/rSVOrzkMoZ
Research:
https://t.co/hSRIQhO1GO

#ethereum #eth #ethdev #web3 #solidity #erc1337


11:00 AM - 27 Oct 2021




      1
Title: Canto__scaling_through_dynamic_subnets____ephemera
Category: Magicians

Author: tvanepps
Date: 2019-01-10T07:36:03.307Z

link.medium.com



CANTO :: Overview
Scaling Ethereum through ephemeral economies





Hello everyone, at the suggestion of some folks I am posting the writeup I did on Canto. Give it a read if you haven’t seen it yet and share your thoughts - curious to hear peoples’ thoughts, criticisms.
also pinging @zscole / @willmeister / @zscole / @araskachoi
Where’s my shill @mariapaulafn at?

Author: boris
Date: 2019-01-10T08:27:43.127Z

But we already had the @pedrouid comment thread argument on Twitter about whether it’s an L1 or L2 solution
Title: Token_Soulbound_with_recoverability
Category: Magicians

Author: ogarciarevett
Date: 2023-07-12T05:42:12.956Z

This EIP proposes a recoverability mechanism for Web3 companies to restore access to soulbound tokens (non-transferable tokens) in case of loss or security breaches of the original wallet. The mechanism will be applicable to ERC-20, ERC-721, and ERC-1155 token standards.
PR: Add EIP: Soulbounds with recoverability by ogarciarevett · Pull Request #7322 · ethereum/EIPs · GitHub

Author: ogarciarevett
Date: 2023-10-16T05:07:03.379Z

The recoverability could be resolved using the ERC4337 AA, this post is deprecated.
Title: Alternative_proposal_for_the_Ethereum_2_0_serializ
Category: Magicians

Author: jpitts
Date: 2019-02-14T03:54:48.871Z

Péter Szilágyi has proposed Simple Offset Serialization (SOS), an alternative to the Simple Serialize (SSZ) proposed in the Ethereum 2.0 spec.
There is a detailed Twitter discussion between @karalabe, @ricmoo, and @vbuterin about this proposal.
https://twitter.com/peter_szilagyi/status/1095878167309545472

Author: jpitts
Date: 2019-03-02T00:17:00.007Z

This is a better thread to see for this subject: Discussion of EIP-1805
Title: Transaction_failed_in_metamask
Category: Magicians

Author: BigGod12
Date: 2023-11-12T04:33:36.721Z

I need help to transact with my metamask, I sent a double transaction by mistake and now it has been stuck for the past 6 days, I can`t send or swap tokens anymore with my account, at first I keep getting "insufficient “gas” and when I am logging in again my metamask my account keeps showing this error message and I still can’t send any money out of my account
Screenshot_2023-11-11_11_43_101366×768 121 KB
Title: IDEA__allow_contract_addressing_by_ENS_instead_of_
Category: Magicians

Author: Ethernian
Date: 2018-05-29T13:45:58.410Z

From ether-router manual:

Allows you to have a contract with a stable address, but fully controllable and upgradeable behavior.

It looks like a nasty workaround for deeper problem in ethereum architecture, isn’t it?
Guys, we should stop use ethereum addresses as a public ids for mutable entities! We have ENS for that.
It should be possible to address a contract (or even contract+function callpoint) by ENS name.
I know, it requires low-level ENS integration into ethereum core and there are challenges here, but now I am asking you just about the idea.
Does it make sense?
What do you think?

Author: Ethernian
Date: 2019-03-23T23:16:09.528Z

It were objections, that ENS lookup may be prohibitive high.
I would suggest to introduce a global ENS resolution cache for that updated by resolver.
Title: Things_to_decide_for_phase_2__copy_from_eth2_0_spe
Category: Magicians

Author: vbuterin
Date: 2019-03-11T02:34:00.828Z

Virtual machine

Decide definitely doing EWASM (default)?
What does the FFI look like?
How is code serialized? Doing any fancy AST merklization?



Cross-shard message structure.

Here is a possible design with some details: https://ethresear.ch/t/phase-2-pre-spec-cross-shard-mechanics/4970

Mechanics: cross-shard messages, contract yanking
Decide we’re not doing layer 1 synchronous cross-shard calls and leaving it to layer 2 (default) or do something else?



Contract storage structure

Linear code, linear storage, max combined size 12kb (to fit a yank into a single block) ?



Contract addressing

Default approach: CREATE2 for everything
Possible alternative: optional sequential addresses for contract creation (rationale: with much smaller addresses, using libraries may be much more efficient)



Access lists

Total (must specify all addresses) vs partial (can specify prefixes) vs none at all



Account abstraction model

https://ethresear.ch/t/tradeoffs-in-account-abstraction-proposals/263
https://ethresear.ch/t/maximally-simple-account-abstraction-without-gas-refunds/5007
Major tradeoff: do we abstract nonces or not? That is, do we keep in-protocol nonce-checking of transactions or do we leave that to the contract code?

Rationale for abstraction: simpler protocol; also prevents complexities arising from interaction between multiple users attempting withdrawal from one contract at the same time, where N-1 of them must resend with a higher nonce, also removes need to worry about replay prevention in the hibernation/waking cases in-protocol
Rationale for non-abstraction: potential for more guarantees for network peers; preserves invariant that any given txhash appears only once in a chain





Gas cost model

Computation
Data
Access: charge per Merkle branch, don’t charge if the Merkle branch has already been used in that block?
Adopt fee market reform proposal from https://ethresear.ch/t/draft-position-paper-on-resource-pricing/2838 ?



Storage fees

https://ethresear.ch/t/a-minimal-state-execution-proposal/4445
https://ethresear.ch/t/state-fees-formerly-state-rent-pre-eip-proposal-version-3/4996
Hibernation and waking: https://ethresear.ch/t/cross-shard-receipt-and-hibernation-waking-anti-double-spending/4748 (referenced in https://ethresear.ch/t/phase-2-pre-spec-cross-shard-mechanics/4970)
Decide on fixed fee?

Note: even with a fixed fee, there is an implied cap on the storage size of each shard because of gas limits (at least, this is if we charge a gas cost that scales linearly with TTL extension)





What is the above missing?
Title: Chargeback_Tokens
Category: Magicians

Author: bradleat
Date: 2021-02-04T02:40:31.594Z

Awhile ago I submitted an EIP for a Recoverable Token Standard, but it appears that since then this issue has been better addressed by wallets such as Argent or Gnosis Safe.
Building on this work, I was motivated to solve the other part of the EIP which was dealing with a standard for chargebacks. This concept will be important for users who wish to spend their tokens (such as DAI) in exchange for goods or services that they fear may not be delivered.
The basic concept is that we create a virtual “check” which includes a default remedy if a chargeback is requested. Here we can send tokens to the sender, recipient and also another address (such as one for a counterfactual contract which can deal with a recovery process). Transfers also have a blockCount that must pass before they can be finalized. During this waiting period they can be disputed. Either party then may trigger the defaultResolution or may propose other remedies to the situation.
As an aside the method of signing the various hashes needed by this system is delegated to a contract signing method wherein someone in control of a contract can publish a signature that can be consumed by the chargeback token contract.
Besides this the proposal is essentially an escrow for tokens.
Remedies (especially the default Remedy) should allow for a satisfactory recovery of the situation for both parties. This may mean triggering a decentralized justice process for the recovery of the funds, splitting the funds, or (for account with KYC or other incentives to be kept in good standing and uniquely identifying a user) we maybe choose to lookup the account’s history to compute a risk score and use that information to proceed with a chargeback.
As a other option for a good default remedy is to allow the sender to recover a small amount of funds with each future such transfer if they continue to use a system without asking for further remedies. Then after N blocks, the intended recipient can recover the rest of the funds. The idea being that the locking of the funds (to be recovered by future transfers), forces the user to continue using this account if they want to receive their remedy. However, it also allows recipients to understand the risk that the sending account carries. On the other side, if the recipient account is a popular account (for a retailer perhaps), then we can use this information to see if the sender account is requesting more or less remedies than average for a given recipient. This idea in particular needs some work.
You can find a draft implementation for this idea here.
If you have any feedback on this idea, I would very much welcome it! Thanks.
Title: Unsecured_Leasing_NFT_Promotes_the_Development_of_
Category: Magicians

Author: kkimos
Date: 2021-12-01T04:19:25.758Z

This standard adds a new right of Non-Fungible Token that the right to use. Through this standard, you can achieve :

Separation of the right to use and ownership of Non-Fungible Token
Non-secured lease Non-Fungible Token
You can continue to use it after you mortgage the Non-Fungible Token
Metaverse sharing economy

It is precisely because of the separation of ownership and use right that the utilization rate of assets can be greater. You must distinguish between the rights of the user and the owner.
Different from 2615, we only added a right to use, so that we can get all the functions of 2615, and reduce many unnecessary operations in 2615. The explanation is as follows:

The owner should not use some of the ownership rights when mortgage NFT, such as transfer, AXS-like breeding or weapon upgrade, because it is likely to change the status of the original NFT, so when the user mortgages the NFT, the ownership must be mortgaged in the contract middle.
In the case of mortgage or transaction, the owner has the right to continue to use it before returning the ransom or selling it

This is the result of my implementation, you can refer to cryptosharing (cryptosharing) · GitHub

Author: wvans123
Date: 2021-12-01T10:14:55.976Z

Nice proposal for future metaverse sharing economy, wish a new era come

Author: Daniel-K-Ivanov
Date: 2022-02-25T09:19:33.654Z

Hi @kkimos
I think that you can check ERC-4400: ERC-721 Consumer Extension and see if it can be of use to your use-case.
Title: Compute_Units_Estimation
Category: Magicians

Author: a10zn8
Date: 2023-06-16T09:37:04.832Z

Greetings everyone,
I’m currently involved in a project, the primary goal of which is to create a system capable of estimating the relative complexity of each JSON-RPC method. We’re building this in the context of our work on drpc.org, where we’re creating a community of node runners to run a decentralized rpc provider service.
One of the more intriguing challenges we’re grappling with is the construction of a fair model to estimate the cost of calls. To give you an example, the ‘eth_blockNumber’ method is relatively inexpensive, costing about 10 compute units (CUs). The ‘eth_getBalance’ method is slightly more expensive at 11 CUs, while ‘eth_call’ is even more so, with a cost of 21 CUs. The list goes on.
So, how do we create a comprehensive model that ensures a fair and accurate estimation of call costs? I am eager to hear your insights and look forward to the exchange of ideas.

First iteration
In order to establish a baseline for this research, I adopted the following methodology: I selected two distinct Ethereum nodes, Erigon and Nethermind, and tested almost each JSON-RPC method’s performance under varying rps pressures.
So, here’s what I did: I tested the performance of two Ethereum nodes, Erigon and Nethermind, under different rates of requests per second (RPS). I added missing methods to Ethspam (here’s the link: https://github.com/p2p-org/ethspam) and used a load test tool I wrote called Ether Bench (link: https://github.com/p2p-org/ether-bench).
The tests provided a lot of data. The main objective was to create a robust model capable of providing fair estimations comparable to existing Compute Unit (CU) estimations from various public providers. I mainly looked at three things:

How long do requests take at 100 RPS
The maximum RPS where every request is successful
The average response size

I turned these numbers into a scale from 0 to 1 and used them in this formula:
0.5 * latency + 0.3 * (1-throughput) + 0.2 * size
Based on that formula and multiple measurement results, I came to our current cu estimation, which can be found here - DRPC – Compute units

Questions
Now, I need your help. My formula is a guess, and I think we can make it better.
Are there more details we should add? Have you worked on something similar? How would you solve this?
I’m excited to hear your ideas.
Title: Integrating_cryptographic_proof_of_NFT_metadata_ve
Category: Magicians

Author: tim-cotten
Date: 2023-01-13T19:24:38.905Z

I wrote about this vaguely in a primordial soup a month ago, but I’ve since solidified the ideas in a blog post.
Problem: When NFT’s point to optional metadata stored off-chain there is no on-chain mechanism that a browser/wallet can use to validate that the metadata hasn’t been tampered with.
Solution: In Web 2.0 the W3C standardized Subresource Integrity (SRI) which allows resources in HTML to declare their integrity digests & hashing algorithm so the browser can download the resource, hash it, compare it with the declared integrity digest, and then pass/fail the resource. We can do the same on-chain by providing a simple interface for getIntegrity(tokenId) that returns the SRI-formatted hashing-algorithm + base64-encoded integrity digest.
Caveat: browsers/wallets will have to adopt both checking for the interface and validating off-chain metadata, but this can be a powerful tool against future malicious NFT projects.
Full details here:
https://blog.futureofgaming.wtf/making-metaverse-nfts-a-little-more-trustworthy-5e7dd254256
Looking for contributors to help us draft an EIP.
Previous topic where I first thought about the idea: SRI-style Integrity Digests for Tokens
Title: Globally_available_tx_opcodes_in_solidity
Category: Magicians

Author: 0xTraub
Date: 2023-03-21T18:19:12.071Z

I’ve been thinking a lot about the future of account abstraction now that ERC-4337 is live. Is there a reason why there aren’t more globally available variables in solidity. For example, we have tx.origin, which is useful for getting the EOA that initiated a transaction, but why not more? Is there a technical reason these aren’t included (other than a desire to maintain simplicity of the EVM)?
Example:
tx.entryPoint - ENTRYPOINT opcode - Define the top level contract a tx was initiated by calling
tx.data -  TXDATA - Define the top level calldata used in calling tx.entryPoint
tx.value - TXVALUE - The top level value in Ether used to call tx.entryPoint
tx.sig - TXSIG - first four bytes of the calldata used on tx.entryPoint
My main thoughts for how this would be used is to allow future proofing of application-whitelisting under account-abstraction. Currently the standard is to use require(tx.origin == msg.sender || isWhitelisted(msg.sender)). However once everyone switches to smart-wallets this will become unsustainable due to everyone not being able to be whitelisted at scale. Perhaps if you introduced a new opcode for this kind of information you could have whitelist implementations which use things like
require(tx.entryPoint == ENTRYPOINT_CONTRACT && tx.sig == HANDLE_USEROPS_SIG)
This would allow support for smartWallets interacted with through the ERC-4337 entryPoint contract. It would also allow contracts to screen out transactions to prevent attacks like flashloans. Since the top level call must be to the lending contract, no flash loan can occur to manipulate the oracle before the collateral is valued.
It seems like a pretty simple opcode to include without too much technical difficulty to implement by execution-client teams, so there must be some reason it doesn’t exist?

Author: RobAnon
Date: 2023-05-01T20:09:27.812Z

@SamWilsn this is pretty close to what you and I had previously discussed.

Author: SamWilsn
Date: 2023-05-01T20:46:33.244Z

I can’t really speak for the historical reasons why these opcodes don’t exist (I suspect it’s because no one has asked for them yet.)
If I were a core dev, I might push back on these suggestions simply because they increase the surface area of stuff that might break as Ethereum evolves. For example, tx.entryPoint might interact with a hypothetical specification for rich transactions.

Author: 0xTraub
Date: 2023-05-01T21:24:07.642Z

@SamWilsn That’s a very fair point about rich transactions. I think one way to handle this would to just have the opcode return caller if it’s from an EOA. I think the reason this opcode may be needed is because of the future difficulty in identifying the difference in wallet types due to AA. Then you could do things like "if (tx.entryPoint != tx.origin) {}`
I’m open to ideas on potential implementation if you think there’s a market for this kind of opcode.
Title: Scriptable_ERC721
Category: Magicians

Author: wuminzhe
Date: 2021-08-13T01:23:07.260Z

I don’t know if there is already a similar work in progress, if so please let me know.
The current erc721 is static. I think erc721 can be dynamic. This can be done by supporting script.

the creator writes the script, so the creator can control how NFT behaves.
once the NFT is minted, the script can’t be modified.
some parameters in the script can be modified by the NFT owner.
multiple script type support, such as p5js, raphael, etc.

Below is an example of how to extend the ERC721:
interface ERC721Scriptable {
	event ParamsUpdated(uint256 indexed tokenId, string oldParamsURI, string newParamsURI);
	function scriptType() external view returns (string);
	function scriptURI(uint256 tokenId) external view returns (string);
	// hash result of params, protect params from being modified
	function paramsHash(uint256 tokenId) external view returns (bytes32);
	function paramsURI(uint256 tokenId) external view returns (string);
	function updateParamsURI(uint256 tokenId, string paramsURI) external;
}

A p5js script example
function setup() {
  createCanvas(400, 400);
  background(200/*{bgcolor}*/);

  ellipse(200, 200, 80/*{ellipse1}*/, 80/*{ellipse2}*/);
  text('world'/*{title}*/, 10, 30);
}

The params example of the above script
{
	"bgcolor": 100,
	"ellipse1": 60,
	"ellipse2": 60,
	"title": "hello world"
}
Title: Auto_rotatation_Setting_in_PWA
Category: Magicians

Author: fubuloubu
Date: 2019-04-10T14:16:57.611Z

I use this forum (and ethresear.ch) as PWAs on my Android device. For whatever reason, ethresearch PWA respects my chosen OS option for autorotation, whereas this forum’s PWA does not. Seems like some sort of configuration issue to me, but other people have had problems in general. Here is a discourse bug report:


Discourse Meta – 12 Oct 18




Android Auto-Rotate Disabled Not Respected with Discourse PWA




Bug




This only happens with Discourse after you “add to homepage” (creating a Progressive Web App), once added, they don’t respect Auto-Rotate settings and keep rotating even when the setting is disabled on Android.  It’s incredibly frustrating since I...

Reading time: 1 mins 🕑
Likes: 17 ❤

Author: fubuloubu
Date: 2019-05-04T11:26:22.477Z

Solve the bug. Ensure you don’t have auto-rotate turned on when you save the app to your screen and it will respect the OS option.
Title: EIP_911_______circuit_breaker_standard_for_smart_c
Category: Magicians

Author: crypto-pumpkin
Date: 2021-02-26T01:59:21.430Z

This topic is for discussion of a circuit breaker standard for smart contracts.
Some projects have implemented a circuit breaker, including Maker, Cover, Ruler, etc., where a responder (usually a multi-sig) can (and only) pause critical functionalities (chosen by the project) on the smart contract when abnormal activities detected.
Each implementation is different.
One example is on the BonusRewards.sol from Cover Protocol.They have used a list of responders.
A standardized circuit breaker would benefit a lot of projects and enable tons of possibilities like a Global Responder Group DAO who can act as a guard towards exploits.
I am pretty new to the space and wanted to start the conversation here to hear your opinion on this.
Title: Name_needed_for_combined_EL___CL__Prague___Electra
Category: Magicians

Author: abcoathup
Date: 2023-07-20T05:00:23.378Z

A name is needed for the combined EL + CL upgrade (Prague + Electra) after Dencun (Cancun + Deneb) upgrade.
EL upgrade is Prague (Devcon city)
CL upgrade was named Electra on ACDC call 113
Suggestions so far for Prague + Electra:

Petra
Pectra
Practra/Prectra/Pretra/Pektra
Pralectra
Electrague
Elegue
Prague-Electra
E-Prague
PragEl

Please reply with your suggestions, then we can run a poll.

Author: benjaminion
Date: 2023-07-20T13:45:55.126Z

Prague-Electra.
Willing to die on this hill.

Author: smartprogrammer
Date: 2023-07-20T16:13:46.330Z

Anything but “Electrague” is fine by me

Author: Demuirgos
Date: 2023-07-20T16:48:04.263Z

what about  “Practra” or “Prectra”?

Author: matt
Date: 2023-07-20T20:56:58.870Z

I like Petra. (extra characters to appease the forum software)

Author: RenanSouza2
Date: 2023-07-20T22:15:48.979Z

I suggest Practra for the name

Author: sullof
Date: 2023-07-20T23:15:12.967Z

I like Petra.
Or the opposite, Elegue.

Author: Mani-T
Date: 2023-07-21T02:25:10.621Z

abcoathup:

Petra


This one. It was never chosen because it was the shortest.

Author: shemnon
Date: 2023-07-21T15:33:46.229Z

Petra is a fairly famous place in Jordan.  If we want a unique moniker like Shapella or Dencun we would need to add more letters or switch the order.
From that constraint Pretra and Pektra would be my recommendations.
We could swizzle the names, but Prelektrague will be a nightmare to type.

Author: mattstam
Date: 2023-07-22T02:03:52.676Z

+1 for Petra – simplest and easiest to pronounce for different language speakers.

Author: arbora
Date: 2023-07-22T03:48:50.332Z

Throwing Prelec into the ring as being short and capturing the key sounds of both words, without getting too hung up on cramming the literal ending of one or the other in.
Petra is short and sweet, but an actual place (that didn’t host Devcon), unlike previous novel contractions Shapella and Dencun.

Author: aka
Date: 2023-07-23T00:02:51.312Z

I asked chat GPT to recommend a word by combining ‘Prague’ + ‘Electra’ and was offered as below:
1. Praglectra
2. Pragelect
3. Elecrague
4. Elecpra

Author: DoubleB.eth
Date: 2023-07-23T00:36:25.144Z

How about “PralecTricity”?

Author: realHakeen
Date: 2023-07-24T02:02:52.156Z

Pragtra Pragtra Pragtra Pragtra Pragtra

Author: radek
Date: 2023-07-25T20:51:32.466Z

Prague-Electra
Nice opportunity to stop those strange combined names.

Author: mkalinin
Date: 2023-07-27T15:22:19.149Z

Suggesting E-Prague if we want any shortcut to exist, while I am more on Prague-Electra and  interchangeability of these names.

Author: sand
Date: 2023-07-28T01:59:37.868Z

Pragel (or PragEl)
Simple, short and easy to say

Author: abcoathup
Date: 2024-01-05T02:03:53.710Z

@matt named Prague + Electra upgrade as Pectra on all core devs - execution 178
Title: Wire_protocol_post_blockchain_validation
Category: Magicians

Author: dominic
Date: 2019-04-29T07:35:01.042Z

Hi Guys in this group,
reading through the different proposals I would like to propose to split the discussion of

Constrained Blockchain Validation algorithms such as FlyClient and our own BlockQuick and
The wire protocol used after the blockchain has been validated.

While I believe that the discussion will go on for some time for 1), the 2nd question could quicker lead to alignment within the community. And different blockchain validation schemes could still use the same wire protocol.
Just probing for interest in the community here. We’re working on a protocol already to define requests and responses. But I imagine other constrained protocols will have similar needs.
Primarily this is to retrieve block information, account balance & state information. Many of these commands exist semantically already in ethereum RPC majorly missing is though the transport of corresponding merkle proofs. For constrained protocols it’s going to be inevitable to retrieve merkle proofs together with any account information. There is an EIP for ethereum RPC, but I’m not aware of a standardization of constrained devices.
Furthermore what is the communities stance on light clients fetching contract variable values. E.g. you want to inspect a contract state value that is in a variable such as a map[mykey] => value. As an “eth_call” is not trustable, we use state fetching and merkle proofs directly to read variables from account state, but it means we hard-code Solidity semantics about how and where maps are serialized. Any thoughts on best practices here?
Another open question here. What data formats are you guys using for communication? What were the considerations?
As for us as we have been prototyping with json rpc via raw tls - but because of the binary encoding overhead are thinking of format that is keyless and can do binary natively. E.g. ASN1 is an alive candidate for us since all our targeted microchip based devices have within their TLS implementation already an ASN1 parser on-board but usually not much else.
Best
Title: Scaling_Concept
Category: Magicians

Author: solubrew
Date: 2020-08-29T00:56:35.264Z

I need someone to poke holes in a scaling concept that I came up with and can’t seem to get out of my head.  Currently much effort is spent mining the same block and then dumping that work when someone finds the block.  Why could we not implement a staged transaction inclusion scheme that breaks the transactions and miners into groups.  The major issue with this is obviously a double spend attack but what if you only let one transaction per address in the “active” pool at a time?  The last block mined of the active pool would select the group of transactions to be included in all of the blocks of the active pool after the next one this way the 2 groups of miners aren’t reliant on each other.  Various mechanisms implemented to random move miners between groups and clusters.  The division of work could then be clustered and distributed the added benefit here is that by imposing random clustering a 51% attack only has about 3.119% of creating a malicious block.  Any questions or insights into why this wouldn’t be feasible please let me know.

Author: jpitts
Date: 2020-09-01T23:25:53.985Z

Hi @solubrew, thanks for posting this. You might try this topic over on https://ethresear.ch; a lot more folks over there pay attention to the underlying protocol and scaling approaches!

Author: matt
Date: 2020-09-02T15:54:37.645Z

@solubrew what you describe sounds similar to Prism. It aims to i) decrease latency and ii) improve throughput. It achieves this by breaking up the single PoW problem into N problems with N subgroups mining on them and by pipelining the transaction data to consensus nodes to avoid long propagation delays upon solving the PoW puzzle. The nice thing is that Prism uses a sortition mechanism to determine which sub-problem the miner has solved, so one miner can’t easily choose which sub-chain to mine.
I don’t follow why you’d want to only allow one tx per address, but this is something that has been suggested as a DoS protection for Account Abstraction. Might be worth checking out for inspiration.

Author: solubrew
Date: 2020-09-02T22:59:55.883Z

Thanks for the replies I’ll followup on the resources provided.  Spefically about the one transaction per address that is only meant to be 1 transaction per address in a block pool at a time this would stop the potential of a double spend from the same address while allowing other transactions to be validated in parallel.
Title: Invoke_contract_view_method_at_different_block_hei
Category: Magicians

Author: numtel
Date: 2022-03-17T09:18:06.375Z

From my searches, it does not seem possible to invoke contract view methods at a different block height. Although this would probably incur significant gas, it seems like it would allow a contract to use a liquidity pool (or multiple or an average over multiple blocks) as a source of price data since it would mitigate flash loan manipulations.
Is my understanding correct? Would this be possible?

Author: Pandapip1
Date: 2022-03-18T00:38:25.514Z

IIUC, view functions are not actually included in blocks and are instead evaluated by the node (that’s why they cost no gas).

Author: numtel
Date: 2022-03-18T06:42:44.146Z

Yes, of course this is the case but I’m specifically asking about invoking the method from another contract. I’m well aware that I can call the function at any height if I’ve got a node.

Author: Pandapip1
Date: 2022-03-18T11:27:30.756Z

Okay, that makes more sense. That’s out of my realm of expertise now.
Title: Split_validating_nodes_and_data_nodes
Category: Magicians

Author: jori
Date: 2021-10-12T05:52:18.814Z

Solana has broken disk space scalability limitation to decentralization by storing data history on Arweave Blockchain. This has security concerns since they are introducing a third party risk within the security of their own network but it has solved the problem of disk space affecting scalability.
Algorand is trying to compete with Solana by increasing velocity and block space and their approach to the disk space problem is to compress history within their own nodes using ZK-Rollups technology.
These movements should make the Ethereum community think about alternatives to the disk space problem so Ethereum is not left behind on scalability.
This Ethereum Improvement Proposal is to split the nodes in validating nodes and data storage nodes within Ethereum Blockchain. Advantages:
-Block size and velocity can be increased because the limit of disk space is no longer an issue so Ethereum L1 can compete on scalability and velocity.
-Decentralization is not compromised but is increased since now the security of the network has more and different nodes.
-Security is also improved on future shards since shards nodes only validate, data is stored on cross shards data nodes.
-Security could also be improved by forcing a coordinated attack on both the validating nodes and the data nodes (where you not only need to stake but also provide disk capacity).
-If a bold approach to data nodes is followed, this opens the door for new utilities for Ether. Ethereum could become the most secure decentralized storage network and storing demand would increase Ether demand.
I did not find any discussion about this and I think It is a very important topic. Just wanted to open the discussion since I am not a technical guy.

Author: greatfilter
Date: 2021-11-22T05:53:21.741Z

Eth nodes already distinguish between archive, full and lite clients. Full nodes store all the data needed to validate transactions and prune away state that is no longer relevant to future transactions. Lite nodes store only block headers and kinda operate in the way you are describing. The problem is that lite nodes cannot efficiently verify blocks because they must fetch data from remote sources which would add too much latency to the process.
Title: Extension_of_ERC_721_standard_which_requires_signa
Category: Magicians

Author: mechanikalk
Date: 2021-10-21T03:05:14.586Z

Traditionally NFTs are only thought of as assets and not representations of contracts or potentially liabilities.  There are several potential use cases where commercial contracts could be created wherein one or more of the parties in the commercial contract would be identified via NFT ownership.  Moreover, that ownership would potentially carry with it both assets as well as commitments and liabilities.
Unfortunately, this means that to transfer such an NFT the recipient will need to explicitly sign a message that accepts that NFT into their wallet and states that the owner takes on the both the benefits and obligations carried forth with the NFT.
Are there any NFT standards that currently exist or that are in draft form that restrict the transfer of an NFT by requiring the receiving address to sign a message stating the intent to receive the NFT and take on both the benefits and liabilities associated?
A further extension of this could require the receiving address to have undergone some form of KYC which may be represented by an NFT held in that address. Are there any NFTs that currently exist or are in draft form that require the receiving address to have a KYC type NFT prior to being able to transfer a NFT to that address?

Author: poma
Date: 2021-10-21T08:50:42.712Z

If my address owns something of negative value why don’t I just discard the address?

Author: mechanikalk
Date: 2021-10-28T01:56:05.742Z

It could hold a contract that has both benefits as well as liabilities.  For example the deed to a house has benefits, but depending on where it is located it can also have a liability, eg property tax.