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

Author: connectorGamefi
Date: 2022-07-05T06:58:30.068Z

Games using non-fungible tokens to stand for their internal objects including roles, assets etc. and there will be some dynamic data asscociated with them, e.g.

roles in games can change their clothes color
NPCs in games can change their skills
properties in games will have different attributes while different roles obtain

Can we use a simple data structure to store dynamic attributes, like this:
struct AttributeData {
    uint128 attrID;
    uint128 attrValue;
}
// tokenID => attribute data
mapping(uint256 => AttributeData[]) internal _attrData;

And supply some interface to operate those attributes:
/**
     * @dev Attach the attribute to NFT.
     */
    function attach(uint256 tokenID, uint128 attrID, uint128 value) external;

    /**
     * @dev Attach a batch of attributes to NFT.
     */
    function attachBatch(uint256 tokenID, uint128[] memory attrIDs, uint128[] memory values) external;

    /**
     * @dev Update the attribute to NFT.
     */
    function update(uint256 tokenID, uint256 attrIndex, uint128 value) external;

    /**
     * @dev Update a batch of attributes to NFT.
     */
    function updateBatch(uint256 tokenID, uint256[] memory attrIndexes, uint128[] memory values) external;

    /**
     * @dev Remove the attribute from NFT.
     */
    function remove(uint256 tokenID, uint256 attrIndex) external;

    /**
     * @dev Remove a batch of attributes from NFT.
     */
    function removeBatch(uint256 tokenID, uint256[] memory attrIndexes) external;

Through the above data structures and methods, users can convert their in-game payments into on-chain assets.
Title: Is_it_possible_to_use_discounted_Devcon__and___or_
Category: Magicians

Author: chris
Date: 2018-11-10T10:11:51.095Z

Right now there is no incentive to mine on the test net, we can’t give the tokens value by making them fungible as someone could just come along and 51% attack it. What if instead it was agreed that mining a certain amount of test ETH on a new PoW test net would allow you to purchase conference tickets at a reduced rate?
Title: Solidity_0_8_0__Remove_Built_in_Default_Over_Under
Category: Magicians

Author: mudgen
Date: 2020-12-28T00:40:15.108Z

https://github.com/ethereum/solidity/issues/10695
Title: Enabling_LaTeX_on_this_forum
Category: Magicians

Author: mattisstenejohansen
Date: 2018-09-23T21:48:52.932Z

Hey, could someone enable LaTeX for this forum? I know that ethresear.ch has it, and I believe that we should too!
Title: Viability_of_Block_STM_to_accelerate_synchronizati
Category: Magicians

Author: u4ea
Date: 2023-10-19T02:20:32.134Z

Right now I believe all Ethereum clients execute transactions one-by-one (correct me if I’m wrong). The Block STM algorithm was invented and used by the Aptos team to execute over 160k transactions per second. I’ll explain here how it works briefly.
Transactions are executed all at once, and those with conflicting write/read sets (storage slots write to/read from) are re-run serially according to the order preset by the block. This optimistic algorithm allows for massively parallelized waiting for storage results while the CPU is saturated completely with useful work.
Since most transactions in a blockchain workload don’t conflict with each other, it’s possible to run them in parallel and detect concurrency conflicts instead of avoiding them in advance.
I’m wondering to what extent this has been investigated for Ethereum and if so what were the results? Is this a way to scale Ethereum as an L1?
Title: Discussion__Do_We_Need_an_EIP_for_Basic_Interface_
Category: Magicians

Author: 5cent-AI
Date: 2023-04-19T06:20:16.216Z

Recently, many wallet projects are preparing to be built on ERC-4337, but many of them seem to be developing their own independent multi-signature wallet contract accounts. There is no common standard for multi-signature wallet contract accounts, which may bring a series of issues such as interoperability, and may affect the large-scale adoption of ERC-4337.
So, do we need an EIP for the basic interface of multi-signature wallet contract accounts? If so, what basic interfaces do we need? We hope more people, especially developers involved in abstract account-related work, can join the discussion.

Author: 5cent-AI
Date: 2023-04-19T06:24:59.819Z

Personally, I think we need it. I am doing some research on extending Token standards, and to be compatible with EIP-4337, it requires EIP-1271. However, that alone is not enough. It also needs the following basic interfaces provided by multi-signature wallet contracts:
1.Query the threshold of signers.
2.Query whether a certain address is a valid signer.

Author: skyh24
Date: 2023-04-19T06:33:14.154Z

You can see my thinking about problems on AA, we are still working on it: aa-research/EIP.md at main · accountjs/aa-research · GitHub
Title: NFT_Authentication_protocol
Category: Magicians

Author: ankitshubham97
Date: 2022-09-08T07:28:04.614Z

GM!
I have been working on setting up a NFT-based auth protocol. I aim to make it a standard, just like OAuth 1.0/2.0 but I am not sure how/where to start with. I have written a draft documenting what the protocol is. I have also written an SDK which adheres to the protocol to achieve NFT-based auth.
Is this the correct place to seek advice? If yes, could folks guide me how to go about it?
Link to protocol whitepaper: Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
SDK link: authnft - npm
Title: Proposed_Process_for_Assigning_Opcode_Address
Category: Magicians

Author: MadeofTin
Date: 2020-05-20T17:01:07.575Z

It came upon the previous ACD that an author was unclear how an address is chosen for a precompile. I wrote a sample process that uses an EIP registry that tracks all opcodes. An Author would submit a PR to the registry to request an address as part of the processes.
Reasons this might be a good thing.

Clear to Authors how to proceed
The current spec of all opcode/precompiles exists in a single place.

Reasons it might not be a good thing

More complex than necessary
Process for process sake

Some proposed text that could be included in the EIP or EIP-1 .

Process for Assigning Precompile Addresses
Once an EIP containing a precompile has progressed to REVIEW or has progressed to a sufficient maturity* the authors may propose a precompile address through a PR to the PRECOMPILE REGISTRY(TBD). The Precompile Status reflects the EIP status it references.
*The definition of sufficient is arbitered by the EIP Editors and is left to their decision.
Example Format





Value
Mnemonic
δ
α
Description
EIP
Status




0x00
STOP
0
0
Halts execution.
YP
FINAL



Thoughts?

Author: MadeofTin
Date: 2020-05-21T14:26:58.611Z

https://gitter.im/ethereum/AllCoreDevs?at=5ec5628c9832dd6f04649aa4
Some discussion in ACDs

Author: MadeofTin
Date: 2020-05-21T14:27:34.813Z

Suggested Process:
Alexander @shamatar May 20 11:10
I’d say it’s an overkill. I’d say that after EIPs are accepted (implemented and go into the testnet) then continuous chunk of addresses should assigned as it happened now. It’s not necessary to know addresses beforehand. If more than one EIP in a batch requires addresses than in EIP number ascending order each of them gets an assignment. Before finalization even the number of proposed precompiles may change
Martin Holst Swende @holiman 01:02
Final state of precompile addresses might be good to include in hf meta-eips (if any precompile was added)
Title: _ANN__Yolc___a_safe__expressive__fun_language_for_
Category: Magicians

Author: hellwolf
Date: 2025-01-06T08:12:21.614Z

Today is the launch of the technical preview of the Yolc project. It is the first milestone where Yolc can produce a partial ERC20 code deployable to Ethereum networks, demonstrating the key idea of linear-type safety.
Yolc doesn’t rebuild wheels. Yolc integrates with foundry, generates Solidity/Yul code, and Yolc is not a language on its own since programming in Yul is programming in Haskell. What Yolc tries to achieve are:

Being purely functional with linear-type safety and is made for the Ethereum virtual machine;
Embedding itself in the Haskell language before being compiled into Solidity/Yul code;
Allowing you to write safe code in production, a joyful experience for super coders.

Yolc aims to feature parity with Solidity plus additional advanced type-level features by 2025/Q1. At the same time, the prototype of the core of Superfluid protocol v3 will use Yolc.
Please find the complete introduction blog post of the Yolc project here, and follow its progress through your favorite channels listed at linktr.ee/yolc.
I look forward to having you join Yolc’s journey!
Title: How_ethererum_transaction_works_
Category: Magicians

Author: Shweta-hlf
Date: 2022-10-31T13:26:03.492Z

HI team,
I am new to ethereum.can you pls give answers of below points.
How fast transactions are accepted by the blockchain’s network

How much bandwidth it uses,
How much blockchain data needs to be stored and in what way the data must be stored.
Important metrices:

numbers of blocks are added to the blockchain,
block and transaction sizes,
transaction rates



Also,
'- How does blockchain respond to increasing number of nodes

How does blockchain respond to increased number of transactions for one specific node.
Thanks

Author: Ariiellus
Date: 2022-10-31T21:58:12.725Z

Hi!


Tx in Ethereum are accepted every ~12s in what is called slot, and every 32 slots form an epoch. They achieve Finality after 2 epochs


Recommended hardware requirements to run a Full node is 25 MBit/s bandwidth. This will be lower after the implementation of EIP-4844 (blob transactions)


Ethereum stores and manages data using a trie. There three types of the trie in the Ethereum Blockchain:

State Trie
Storage Trie
And Transaction Trie



Important metrices: https://beaconcha.in/

After The Merge a block or “slots” is added every ~12s
Each slot can store up to 256 bits (32 bytes ).
21000 is the minimum amount of gas an operation on Ethereum will use.



The most “tangible” answer is that Gas prices will rise due to supply and demand law.  https://etherscan.io/gastracker

Author: Shweta-hlf
Date: 2022-11-01T06:36:09.780Z

Thanks a lot for your reply!!
How ethereum respond to increasing number of nodes
How does Ethereum respond to increased number of transactions for one specific node.
Title: Which_things_need_ERCs_and_which_don_t
Category: Magicians

Author: fulldecent
Date: 2022-09-30T17:55:19.821Z

Originally posted at: What kinds of things should be standardized? – William Entriken Blog
tl;dr A standard only deserves to be written if multiple people adhere to it and people depend on it’s surface area.
An easy, low-effort, low-quality way to find a bunch of things to standardize is to find a popular repository of smart contracts, and then write every one of them up with a short rationale. This is fun for practice, but please do not publish these as it will be a waste of other people’s time to read. Nobody depends on these details.
Unfortunately the EIP repository is a magnet for people to try and publish things that have no need to be published let alone standardized. Of course the reason why is some people see an ERC as a status symbol (it isn’t) or a guarantee of commercial success (it isn’t).
But if you really WANT to make something and standardize it, here’s how.

Go make a thing that is useful
Make it successful
Make other people want to interoperate with your thing
Make other people want to copy you
Then go standardize it

Please see the longer article discusses further and compares to standards in other realms (food labeling, paper sizes, USB) to further illustrate the point. But I hope this thread can make some consensus that the main kind of ERC application standards we want to see are multi-implementation (producer) specifications that actually will be used by some other software (consumers).
This is a higher threshold than just “anything I can write a standard for or that somebody 10 years from now might find helpful”.

Author: gcolvin
Date: 2023-02-03T00:31:41.290Z

You might want to join the discussion here, @fulldecent: Proposal: Forking ERCs from EIPs Repository

Author: fulldecent
Date: 2023-02-03T01:18:37.966Z

Thank you for the heads up!
Added all my notes here Proposal: Forking ERCs from EIPs Repository - #9 by fulldecent
Title: ___Create_a_new_ERC_Section_to_complement_the_exis
Category: Magicians

Author: sbacha
Date: 2023-11-01T21:31:33.365Z

The title says it all comrades, ERCs must have their own commanding heights.

Author: matt
Date: 2023-11-02T01:32:47.505Z

It has been created! Thank you!
Title: _CLOSED__Opcode_to_transfer_ethers_into_block_rewa
Category: Magicians

Author: rumkin
Date: 2020-05-11T15:23:47.959Z

Abstract
Some contracts uses fees as a spam protection. This money mostly are using as a reward to contract owners, but for simple contracts like registries the fee size could be illogically big as a reward for zero activity from the contract owners. It’s especially relevant when we talk about socially meaningful contracts. And it seems fair enough to transfer this fee into a block reward. Seems like it requires a new opcode for this.

 I feel like I saw this idea before, but I couldn’t find the EIP for it. If it’s so provide a link please.

Author: wjmelements
Date: 2020-05-13T02:05:40.548Z

There is the COINBASE opcode and so you can CALL with COINBASE as the recipient arg. We don’t need a special opcode therefore.

Author: rumkin
Date: 2020-05-13T09:43:38.134Z

Thanks. It was lame
Title: P2P_exchanges_parsers
Category: Magicians

Author: p2pforks_space
Date: 2023-09-09T19:19:22.147Z

Hi there! Recently I started in a crypto arbitrage on P2P deals. If you aren’t familiar, its based on the offers to buy crypto with fiat and sell crypto to fiat back with positive margin. So the main job - finding profitable chains between fiat, crypto, payment methods, limits and exchanges. Its a big deal to collect all information on hand and get it on time, and after some tries I been stuck in the excel, spreadsheets, notepad. In order to solve this problem I started to find services with that data, and I haven’t found something even a bit close to my expectations. Do you know any services?
Title: Should_external_links_be_allowed_prohibited_restri
Category: Magicians

Author: xinbenlv
Date: 2022-09-06T02:04:36.600Z

Hi editors and authors who care about links, there is an active discussion about an Editing policy whether to allow/prohibit/restrict external links from an EIP. I love to bring this to your attention and invite you to voice your opinions because I think the referencability of EIPs are important to the culture and technical composability of future EIP.
Here it is the thread Advocate for EIP editors to clearly explain the **current** external link policy to new authors. · Issue #5597 · ethereum/EIPs · GitHub
Title: Interact_with_your_Smart_Contracts__eth_blockchain
Category: Magicians

Author: khiem20tc
Date: 2022-12-29T15:40:44.021Z

Hi everyone!
I’m developing an npm package to help interact with Smart Contracts on the EVM platform (Ethereum, Binance Smart Chain, Polygon,…). My package help clarifies the workflow of transaction through 3 steps below:

Create raw transaction
Sign raw transaction
Send raw transaction

So, you can integrate it into your Frontend and Backend both, this helps your DApp minimize, clarify modules and help for customizing transactions.
In the future, I will develop more utils and tools for Web3 in many next versions.
Using and feedback for me: eth-blockchain-helper - npm
Many thanks!
Title: This_forum_should_merge_with_ethresear_ch
Category: Magicians

Author: panekkkk
Date: 2018-12-31T00:03:14.199Z

This forum is starting to compete with ethresear.ch and covers similar topics. This unnecessarily dilutes attention and mental potential and social scalability. I would suggest merging if at all possible.

Author: boris
Date: 2018-12-31T00:23:32.610Z

Thanks for the feedback!
Definitely some overlap, but a lot broader, non-research topics here too. I think part of the reason that EthMagicians started was precisely because of the desire to discuss non-research topics, often more closely related to implementation and “production” code.
As well, this past year has seen a growth into broader non technical topics, from education to event planning.
So, I’m not personally in favour of EthResearch merging into EthMagicians — but happy to consider it if others are interested!

Author: panekkkk
Date: 2018-12-31T00:38:55.004Z

Hey Boris!
My post stemmed from some confusion among friends around where a particular thread (in relation to staking economics) should be posted to get more attention. Friend was concerned that Magicians forum was taking brains and eyeballs away from ethresear.ch.
Totally understand the need for unique forums that deal with other topics but important discussion items that overlap can lead to some brain drain/dilution. Not sure what the solution is! Double post with one post linking to the other?

Author: boris
Date: 2018-12-31T01:10:23.892Z

I would say EthMagicians is adding eyeballs and brains 
I would suggestion actually gathering the people interested and either forming a working group and/or agreeing on a tag for anything that is long term important. And having group participants choose the main channel.
So, something like an “announce” post — “hey we plan on discussing staking economics, please use tag YYY on group XXX if you want to get involved”.
Feel free to ask for a #working-groups to be created if that’s useful.
So if you want to have the discussion live on EthResearch but think there are useful stakeholders here — announcing it here seems like a good solution.
Probably would be good as well to explain notifications for categories and tags, too. Not too hard to follow many Discourse based forums if you choose to just watch / get notifications for some tags.

Author: PhABC
Date: 2019-01-02T00:43:23.837Z

It’s a bit hard to properly draw a line between what goes where and definitely not rigid, but my mental model of both is as follow :
ethresear.ch: Research related topics, such as cryptography, math, consensus protocols, data availability, scalability, L2, etc.
ethereum-magicians.org: Engineering and politics related topics, such as client optimization, systems and networks, governance, forks, ethereum related events, ERCs, EIPs, etc.
Looking at the latest posts is another way to see which topics is better suited for which of the two communities:
image2031×997 431 KB
I personally disagree that both websites should merge as they serve different communities, which will indeed overlap on some occasions.

Author: virgil
Date: 2019-01-06T08:55:50.287Z

ethresear.ch and magicians are unlikely to merge.
Title: Block_reward_can_be_replaced_by_miner_extractable_
Category: Magicians

Author: wjmelements
Date: 2020-05-12T00:34:00.982Z

Miner extractable value is not the problem or a danger; it is potentially the end of inflation. We can stop issuance completely if miners can make enough from MEV. Better than eradicating this revenue or expending resources to identify and quantify it generally (which may be impossible).

Recent research shows that the revenue that can be extracted from this (called “miner-
extractable value ” or MEV) is potentially significantly higher than transaction fee revenue.

Quote from:



Ethereum Research – 15 Jan 20




MEV Auction: Auctioning transaction ordering rights as a solution to Miner...




Economics






mev





Special thanks to Vitalik for much of this, Phil Daian as well (& his amazing research on MEV), Barry Whitehat for also coming up with this idea, and Ben Jones for the rest!  Blockchain miners (also known as validators, block producers, or...

Reading time: 14 mins 🕑
Likes: 91 ❤
Title: Eth1___Eth2_Merger_Discussion
Category: Magicians

Author: jpitts
Date: 2020-07-24T23:09:32.054Z

This is a critical community “Ethereum roadmap” discussion which has been the focus of several in-person discussions, including in 2018 Prague and 2019 Osaka.
The content below paraphrases @djrtwo’s comments on the matter from his recent “Eth2 quick update no 13” blog post.

I want to give a quick update on the eth1+eth2 merger progress and to give a huge shout-out to Mikhail (TXRX) and Guillaume (geth) for their excellent work.
The current vision of the future of Ethereum is for the current chain to be integrated into the new eth2 consensus as a shard. This is the marriage of eth2 clients (consensus) with eth1 clients (highly optimized user layer) into a single system.
The high level on the client relationship can be found here:




Ethereum Research – 7 Apr 20




Eth1+eth2 client relationship




The Merge




eth1+eth2 client relationship Since Vitalik proposed an Alternative proposal for early eth1 <-> eth2 merge in Dec 2019, there has been an active conversation about what this merger might look like from a software perspective and an eagerness...

Reading time: 9 mins 🕑
Likes: 16 ❤







More detailed scope of the merger discussed by Mikhail is here:




Ethereum Research – 6 May 20




The scope of Eth1-Eth2 merger




The Merge




Thanks to @timbeiko, @djrtwo, @gballet for discussions and comments.  This write up is the follow up to @djrtwo’s Eth1+eth2 client relationship. Taking the separation of duties outlined in the previous document as the foundation, it aims to define...

Reading time: 5 mins 🕑
Likes: 13 ❤







Discussion of the architecture of a geth based eth1-engine (called Catalyst) by Guillaume is here:




Ethereum Research – 22 Jun 20




Architecture of a geth-based eth1 engine




The Merge




This is a proposal for an eth1 engine based on geth, called Catalyst. Thanks to @mkalinin and @djrtwo for their valuable input.  This post presents a general overview of Catalyst, an eth1 engine[1] based on geth.  Catalyst is the name of a...

Reading time: 1 mins 🕑
Likes: 10 ❤
Title: How_successful_are__listed__smart_contracts__dapps
Category: Magicians

Author: pieterhartel
Date: 2019-04-17T02:41:25.364Z

I am a university researcher (See https://itrust.sutd.edu.sg/people/researchers/pieter-hartel/ ). I am asking you, as a developer on Ethereum, to spend 15 minutes of your time to complete an anonymous questionnaire on the success of smart contracts. I am hoping to learn what makes smart contracts successful and I promise to share the results with you via a followup post. Please find the link to the questionnaire here: https://utwentebs.eu.qualtrics.com/jfe/form/SV_0lm2Lfu84u0lurH
Title: Where_is__uint256___memory_tokenTraits__defined_in
Category: Magicians

Author: RustBucket45
Date: 2022-02-28T15:57:31.753Z

Hello,
I’m looking into NFT contracts and I am analyzing the infamous CREEPZ INVASION GROUNDS contract.
Viewable at https://etherscan.io/address/0xc3503192343eae4b435e4a1211c5d28bf6f6a696#code
On line 307 of  CBCStaking.sol,  the function _setTokensValues takes two arrays from memory as arguments, which are used to set the yield value ($loomi token) for a staked NFT. They are uint256[] memory tokenIds, and uint256[] memory tokenTraits.
function _setTokensValues(
      address contractAddress,
      uint256[] memory tokenIds,
      uint256[] memory tokenTraits
    ) internal {
      require(tokenIds.length == tokenTraits.length, "Wrong arrays provided");
      for (uint256 i; i < tokenIds.length; i++) {
        if (tokenTraits[i] != 0 && tokenTraits[i] <= 3000 ether) {
          _tokensMultiplier[contractAddress][tokenIds[i]] = tokenTraits[i];
        }
      }
    }

How was data first input into those arrays? Where are they first defined? tokenTraits[] in particular only exists in CBCStaking.sol as arguments for functions. Outside of that it is not present in any other creepz contracts.
How do they do it? If they are derived from the metadata somehow, where is the function responsible

Author: weiscracker
Date: 2022-07-23T13:21:38.896Z

It’s provided to the “deposit” function which in turn calls _setTokensValues. Your clues are the _ in front of the function name which can indicate something is an internal function or variable, and the fact that _setTokensValues is declared as an internal function. This means it only gets called by another function inside the same contract. So it looks like this is done via website most likely and they call the deposit function with the “correct” traits and sign it so that the contract knows it came from the website and not me or you spoofing the “wrong” traits.
Title: Collaborate_to_create_standard_for_Fractional_NFT
Category: Magicians

Author: Shilpan
Date: 2021-11-30T09:11:10.659Z

The world of NFT has experienced an explosion in recently. We are also familiar with some NFTs selling for exorbitant prices. I have noticed a serious desire, from the broader community, to own a fraction of such NFTs.
In the traditional art market there are ways in which fraction ownership of physical art is achieved. The most common way is

Create a Pvt. Ltd or an LLP company that owns the painting and then sell shares in the company and trade them on specialised exchanges.

For NFTs there are organisations that follow a similar approach. They draw up a smart contract that owns the NFT and gives out fungible tokens for fractional ownership and DAO voting rights.
This approach works but it is not standardised and different contracts sometimes come up with creative deflationary conditions that’s hard to track for first time buyers. It can also result in SCAMS.
I propose to collaborate and create a Standard that allows artist to easily, put up their NFT into a smart contract, fractionalise it and create a DAO token for the bidders.
Considering the future of Virtual Worlds and the essential roles of NFT in this virtual world it is essential to allow fractional ownership of digital art. Fractional ownership will also allow creators to licence and distribute content over internet without fear of piracy. For example. Artists can sell fractional NFT to their album freely accessible online, requiring to prove ownership of a fraction to play the album.

Author: julesl23
Date: 2021-12-01T00:35:46.166Z

There is a PR for this already NFT and FT with Royalty Distribution System #3601
Not sure how far this has got to.
Title: Introducing_Eserialize_Tool
Category: Magicians

Author: stev
Date: 2019-10-31T18:32:41.420Z

Hello EthereumStack developers. We’ve released an easy-to-use deserialize interface at https://eserialize.com/. It utilizes the eserialize library we use in Jade Explorer (an open-source explorer for EVM based networks).
This can help your development of DApp interfaces for ETH, ETC, and beyond.
Title: Enterprise_Feedback_Process
Category: Magicians

Author: timhc22
Date: 2021-05-13T19:38:43.345Z

Hello, I’m new here, so hope this is the right place to post this.
Quick background: I’m semi-connected with the Baseline Protocol team (although am not working for them officially at the moment), and heard some talk on the topic of “how can feedback from enterprises be gathered and turned into proposals for changes to the core Ethereum protocol”…
I made this Proof of Concept site: https://eip.design as the possible beginning of a way of doing this, but from further conversations and research, I’m not sure if it is the best way to move things forward. The idea is for an ‘Enterprise friendly’ dashboard through which feedback would come to the core protocol devs (i.e. first and foremost to @MicahZoltu and then to the core devs if appropriate).
Any thoughts or feedback (or collaboration GitHub - unegma/eip.design) would be most appreciated, either way, I am interested in helping bridge the gap between enterprise Tech leads (who are on a very specific ‘frontline’, and may or may not know a lot about blockchain tech), and the Ethereum team itself (who I’d hope would benefit from this kind of feedback ‘supply-chain’).

Author: MicahZoltu
Date: 2021-05-14T03:03:25.658Z

timhc22:

(i.e. first and foremost to @MicahZoltu and then to the core devs if appropriate


I don’t think you want me to be a gate to protocol improvements.
If you are working with Enterprises who have access to resources, I think becoming (or sending or sponsoring) a contributor is probably the best course of action.  There are a ton of protocol changes that are desired and even planned out, but we simply do not have the engineering manpower to formally specify or implement them all.
Title: _primordialSoup_Best_Practices
Category: Magicians

Author: bumblefudge
Date: 2024-04-24T17:52:34.948Z

On today’s EIPIP call, there was a discussion about how best to use this category, and eth-mag generally.  Opening this thread as a placeholder for some central location/URL that gathers over time tips on how to gather feedback for future/potential EIP drafts.
Eth-Mag tips in general:

The first message in a thread can be updated over time: add a summary! add links to side-conversations, implementations, and community-call notes/recordings!
Moderators can do this^ in an emergency, but it’s always best if a thread/EIP driver takes this seriously and does it over time

Primordial-specific tips:

Feel free to cross-link or break out separate threads for prior-art review or extended discussion of “analogies” (e.g. how PYP handles X or how non-blockchain DAGs have specific properties that might be useful in ethereum, etc)
Title: Post_Quantum_Solidity_Storage_Slot_Risks
Category: Magicians

Author: ryley-o
Date: 2025-03-03T21:48:47.747Z

Consider the following:

existing immutable smart contract (e.g. erc-20) has mapping(address account => mapping(address spender => uint256)) private _allowances;

In a post-quantum world, Grover’s algorithm weakens preimage resistance, reducing the difficulty of someone being able to brute-force overwrite a specific approval storage slot from 2^256 to 2^128. While still decent, this may be breakable in 20-30+ years.
This problem is generalizable to many, many situations in solidity, because fundamentally, solidity maps all contract storage to deterministic slots based on keccak256 hash of something controlled by often untrusted third parties.
If I’m designing a smart contract that I want to remain secure in a post-quantum world, but I don’t want to make it upgradeable (which has its own uncertainties and issues), what tools are we providing developers to get ahead of this problem? Are there discussions of alternate hashing function precompiles to make available to developers in the near term, without them paying significant gas penalties? It seems that we should be incentivizing post-quantum smart contracts for our protocol’s long-term outlook.
An entirely separate concern of mine is how legacy, non-upgradeable smart contracts will remain secure in a post-quantum world, so any discussion in that area would also be great in this thread!
Title: Mosaic_to_scale_dapps_asynchronously_on_chain
Category: Magicians

Author: schemar
Date: 2018-10-24T12:02:44.970Z

Dear Magicians,
we are implementing a BFT scaling solution for dapps that runs on-chain and we are looking for your feedback and questions.
We extend the state and transaction space by adding auxiliary systems (side-chains) and only committing roots back to Ethereum.
In very simple terms think of it as a combination of Casper FFG and sidechains.
One difference to Plasma is that we have an open set of validators that is staked on Ethereum. That set of validators observes the side-chain and commits state roots. Furthermore, the asynchronous nature does not put a time constraint on a mass-exit.
One difference to Ethereum v2 (shasper) is that we can add an arbitrary number of side chains. In future work it can be extended to a second order depth of finalization. Mosaic would run on Ethereum v2 as well, of course.
You can find the current draft of the paper here:

raw.githubusercontent.com



mosaicv0.pdf
1561.96 KB





From the abstract:

Mosaic is a parallelization schema for decentralized applications. It introduces a set of Byzantine fault-tolerant consensus rules to compose heterogeneous blockchain systems into one another. Decentralized applications can use Mosaic to compute over a composed network of multiple blockchain systems in parallel.
The Mosaic consensus rules are asynchronous and as a result the state transitions of the meta-blockchain can span an arbitrary time length and an arbitrary amount of computation. This includes the exit procedure.
The computational effort required by the origin blockchain to (challenge and) commit a meta-block is constant in the computation executed and scales linearly in the number of validators.

We are very interested in critical feedback and questions.
One open topic, which we also haven’t solved yet, is the proving of an invalid state transition in the case when more than 2/3 of the validators collude.
The source code is work-in-progress and lives here: GitHub - OpenST/mosaic-contracts: Mosaic-0: Gateways and anchors on top of Ethereum to scale DApps
If you want, you can also ask your questions on https://discuss.openst.org
Title: Upgrading_the_EthMagicians_multisig__adding_some_p
Category: Magicians

Author: boris
Date: 2019-08-27T11:46:05.697Z

This is a thread for extended discussion on extending the multisig holders for the EthMagicians wallet:
https://github.com/ethereum-magicians/scrolls/issues/68
TLDR @meknab & @Flash are being added.
@meknab has some basic rules that she will document.
We are likely to have some other things to discuss related to Osaka and ongoing.
Title: Toolkit_for_planned_changes_forks_on_testnet
Category: Magicians

Author: jpitts
Date: 2018-10-21T20:05:41.799Z

I’ve seen various comments on Twitter and direct, as well as discussion at EF DevOps about having better planning and documentation with testnet deployments. Some that stand out in particular are: 1. creating institutional knowledge and 2. ways we can enlist more help in the process.
I’ll start the thread here and collect some of those discussing this.
For background, start with this thread: Lane Rettig’s Retrospective & comments.
Initial work is on a DevOps Retrospective, in order to discuss what happened and what can be done / put into the toolkit.

Author: fubuloubu
Date: 2018-10-22T04:46:09.820Z

This is great!
I think regarding “enlisting more help” for mining (eventually validating) on testnets, there will never be incentive to mine unless we make incentive to mine. One way would be to set aside some money to award mining for a specific length of blocks for the final test period. This is after a period of initial integration testing between client developers.
Awards could be given manually to the addresses that mine during the period (if it was considered stable enough to award) at a rate of 0.001 mainnet ETH to 1 testnet ETH. You would ideally get 1/1000 of the total difficulty/stake (if properly advertised), which would correspond with what should be expected for the mainnet release. For PoS, I think staking tokens could be freely given so inadvertent slashing isn’t a concern, we would just award fees and block rewards manually to the stakes addresses to conduct our final, incentivized test.
I also think we should give up on advertising the non-incentivized PoW/PoS test network for anyone other than client devs and people testing mining upgrades or whatever. Smart contract testing needs a way more stable environment for conducting tests (like Rinkeby), and that should be the best practice/common wisdom everyone should have.
Title: Geth__Cliff_and_Windows_are_not_friends_with_each_
Category: Magicians

Author: OneOneExe
Date: 2023-07-07T17:29:33.666Z

Hi all. I wrote about this problem on GitHub, Discord, StackExchange but no answer. Might help here.
OS: Windows 11
Setting interaction between Clef and Ceth via Named Pipes
In accordance with the instructions from Getting started with Geth | go-ethereum
enter commands sequentially:

In cmd:
clef --keystore geth-tutorial/keystore --configdir geth-tutorial/clef --chainid 11155111
In a separate cmd:
geth --sepolia --datadir geth-tutorial --authrpc.addr localhost --authrpc.port 8551 --authrpc.vhosts localhost --authrpc.jwtsecret geth-tutorial/jwtsecret --http --http.api eth,net --signer=geth-tutorial/clef/clef.ipc --http

Finally Geth reports:
Fatal: Failed to set account manager backends: error connecting to external signer: Invalid pipe address ‘geth-tutorial/clef/clef.ipc’.
What am I doing wrong?
Title: API_Monitoring_Tool_Research_Needs
Category: Magicians

Author: RYO
Date: 2022-07-24T05:09:32.691Z

Hello, I’m the developer of Ethereum, I’m searching the Address monitoring tool and API monitoring tool now. I have researched many platforms, but they all provide single-node RPC data. Is there an API tool like Tokenview（https://services.tokenview.com/en/invite?utm_source=redit&utm_medium=link&utm_campaign=dev11）that directly provides encapsulated data?

Author: abcoathup
Date: 2022-07-27T07:05:16.609Z

@RYO I assume you mean that you develop on Ethereum rather than you are the developer of Ethereum.  You may want to tidy up this language.

Author: esaulpaugh
Date: 2022-08-14T23:20:27.016Z

Ethereum is an open project and so we are all the developer.
Title: BarnBridge_DAO__Built_for_the_Future
Category: Magicians

Author: mudgen
Date: 2020-12-27T16:23:20.404Z

https://medium.com/barnbridge/barnbridge-dao-built-for-the-future-3735fbd671c5
Title: Token_curated_blacklist_of_scam_addresses
Category: Magicians

Author: dadabit
Date: 2022-05-29T18:49:32.314Z

I wonder whether anyone discussed or proposed token curated lists as a decentralized governance of blacklists of scammer addresses.

Author: toledoroy
Date: 2022-05-31T23:42:10.732Z

There’s at least one project I know that’s working on this: YourJustice.life
and probably others as well
Title: Council_of_Paris___Token_Ring
Category: Magicians

Author: AdamDossa
Date: 2019-02-20T20:49:31.211Z

I have added some details to the Token Ring event during the Council of Paris with some suggested topics.
It is focused on using tokens to represent securities. There will also be a DeFi track at the conference with lots of related material and presentations (including myself).
Please add any topics you’d like to see discussed and your interest to the HackMD document at:


HackMD



Council of Paris - HackMD





Thanks,
Adam

Author: julienbrodier
Date: 2019-02-21T13:30:57.440Z

Hi Adam,
The link seems to be protected.
Can you please have a look to the permissions ?
Thanks !
J.

Author: AdamDossa
Date: 2019-02-21T14:01:50.767Z

Yep - this seems to be the case. It is being discussed at:



HackMD document is now protected? Happenings


    The previous link: 
https://hackmd.io/DaJhrasLQteUk3IwX5bQAg 
gives me a 403 error. 
Anyone know what’s up with this? 
Thanks, 
Adam
Title: Exploring_the_Potential_of_Multiple_RPC_Node_Provi
Category: Magicians

Author: Allyn
Date: 2023-11-06T20:40:07.725Z

Hello Ethereum Magicians! 
I wanted to start a discussion about the advantages and challenges of using multiple RPC node providers for blockchain requests. This approach can significantly enhance the reliability and performance of blockchain applications.
Here are a few points to consider:

How can multiple RPC node providers improve the uptime and scalability of your applications?
What challenges have you faced when working with multiple RPC providers?
Are there any specific use cases where you see the most benefit from this approach?

I’m eager to hear your thoughts and experiences. Let’s dive into this exciting topic together! 
Please share your insights and join the conversation!

Author: ake
Date: 2024-06-18T02:26:23.352Z

Just stumbled on this. Mostly on your first point, the biggest problem I had is being able to reliably receive smart contract events as they come in. This one always has issues no matter the RPC provider. And when you need to reliably receive the events, they are most of the time are critical or almost critical to your setup.
The best way to go about this seems to be to set up a redundant event listener with multiple RPC node providers, eg with the top ones.
Here’s examples with web3.py, web3.js & ethers that we built at our Chainstack developer portal.


Ethereum: How to set up a redundant event listener with Python


Ethereum: BUIDLing a redundant event listener with ethers and web3.js
Title: Should_there_be_an_economic_review_of_EIPs_
Category: Magicians

Author: jpitts
Date: 2018-04-18T20:07:04.091Z

Currently the AllCoreDevs and now the Fellowship of Ethereum Magicians provide technical review of EIPs. When this work is performed, are engineers responsible for evaluating the economic implications (macro and crypto)?
A large amount of the thinking that went into the core protocol, and now going into Casper, Sharding, and so many other initiatives involve crypto-economics. As blockchains become more similar to traditional economies, initiatives may need to also consider macro-economics.
How is the community to know that expert economic review has been performed and consensus reached about the feasibility a proposal?

Author: fubuloubu
Date: 2018-04-19T03:03:37.643Z

This is an extremely important consideration. Also, what testing has been done to show that the economic mechanisms operate consistent with their intended purpose at scale with a simulation or game? Technical correctness is also important, but economic design is arguably more important to show in the broader context.

Author: lrettig
Date: 2018-04-19T15:27:05.522Z

Want to add my support for how important this is, although I don’t have an answer to your question yet:

How is the community to know that expert economic review has been performed and consensus reached about the feasibility a proposal?

As a starting point it may be worth discussing the way this works today. My understanding is that it’s (surprise surprise!) very informal and that certain individuals with experience in cryptoeconomics/incentive mechanism design, such as @Arachnid, weigh in with valuable opinions on the All Core Devs calls. We also get a lot of armchair economists weighing in on the EIPs and on Reddit.
Would it be worth considering adding an “economic implications” sections to EIPs, where relevant?

Author: fubuloubu
Date: 2018-04-19T15:53:57.587Z

lrettig:

Would it be worth considering adding an “economic implications” sections to EIPs, where relevant?


Yes! “Economic Considerations” and maybe “Network Considerations”
Just getting the conversation started on those two topics, a little bit of the author’s insight into how this might affect things, that would be very useful.
Title: Ethereum_2_0_Implementation__A_Decentralized_Proce
Category: Magicians

Author: Dan-Kioria
Date: 2023-05-16T14:39:55.824Z

As an outsider to the Ethereum community, and for that matter the blockchain community, allow me to express my admiration, and even amazement, at an accomplishment that I would have thought was impossible: creation of a viable currency, exhibiting both fungibility and double-spend prevention, that is not issued by any central banking authority.
A big Bravo! for that accomplishment – and indeed for the blow it strikes against authoritarianism and for democratic governance of the world’s information infrastructure! This is truly a new age.
And yet a thinking person can’t help but wonder how a well-planned and managed process such as the staged transition from proof-of-work to proof-of-stake could be performed by a collection of unidentified individuals in a purely democratic and trustless process.
Are we to believe that Vitalik Buterin had no more to do with that project than any other holder of similar amounts of Ether? Was the Ethereum Improvement Proposal EIP-1011 just crafted by the Ether-holding masses in one big collective effort?
Well of course no one is suggesting anything of the sort. The fact is that decisions about Ethereum’s direction and day-to-day management are made by a core of individuals who understand its complexities. Might one say that those individuals are in… positions of… um… dare we mention the word “authority”? Isn’t this authoritative group central to the success of the effort?
Transactions can be managed by an algorithm. You could say that transactions can be governed by an algorithm. Again, before Satoshi Nakamoto’s famous paper, no one would have thought that possible, but the notion of fully automated authority-free currency transactions has proven itself to be viable in practice.
But Development and implementation efforts, unless they are performed completely by an AI, require decisions made by human beings who are in a position of authority to make those decisions. Those efforts must be governed. And as the decentralization advocate Lawrence Lundy-Bryan has noted, “There is no such thing as decentralized governance.”
There is good governance and bad governance and everything in between. The thing that has created all the energy behind decentralization is the incessant, habitual, compulsive abuse of power that we see coming from existing governments, corporations, and other institutions. Individual politicians, bureaucrats, parties and cabals incessantly look for ways to circumvent statutory and policy limitations on individual power.
Read further at Ethereum 2.0 Implementation: A Decentralized Process?

Author: abcoathup
Date: 2023-05-17T03:56:36.111Z

ethereum.org



Ethereum Governance
An introduction to how decisions about Ethereum are made.





Anyone can create an EIP
Anyone can voice an opinion on upgrade scope: Cancun Network Upgrade Meta Thread
Core dev calls are public, alternating between All core devs - execution and All core devs - consensus every week.
Title: Name_bound_tokens
Category: Magicians

Author: TimDaub
Date: 2022-05-24T14:01:21.188Z

Keywords: Non-Tradable, non-separable, Non-transferrable, non-fungible tokens, NFTs, Soulbound tokens, SBTs, badges, ENS-bound tokens, Name-bound tokens

EIP-XXXX DRAFT: Add initial draft for Name-bound tokens by TimDaub · Pull Request #5107 · ethereum/EIPs · GitHub

Feedback, discussions, and comments are welcome.

Author: tomcohen.eth
Date: 2022-05-24T20:55:54.509Z

Just to kick off the discussion here - there are two paths forward here I’d be interested in getting input on:

The ERC as it stands, with binding to ENS nodes specifically.
A broader ERC for binding ALL ERC721 token, with an interface similar to what @MicahZoltu suggest in the ERC4973 discussion - returning (address erc721Contract, uint256 erc721TokenId)

Tim’s position is that binding to ERC721 is too broadly general with unclear advantages, whereas binding to ENS has a clear motivation behind it. Basically a standard should have the clearest possible purpose and the tightest definition that serves that need. @TimDaub am I characterising your position here accurately?
Personally, I don’t see the harm in providing a general standard as long as it satisfies the ENS subset to the same degree. My current position is that standards should allow for the broadest possible room for use that can still provide the same guarantees as a tighter standard. Relatively strong position, but will try to have it loosely held.
Title: Should_Diamond_Loupe_Functions_Return_Tightly_Pack
Category: Magicians

Author: mudgen
Date: 2020-08-31T22:53:35.023Z

twitter.com



Nick Mudge 💎 (@mudgen) on X
@mudgen

If you are a software developer I need your help. Should diamonds use an efficient packed data encoding or should they use standard, easy to work with ABI coding?  See this blog post to evaluate and help make the choice: https://t.co/GbqmrGwPSm #ethereum #solidity