Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 28 19:45
    @Arachnid banned @merkle_tree_twitter
  • Feb 17 00:56
    @jpitts banned @Aquentson_twitter
  • Apr 09 2018 04:14
    @holiman banned @JennyJennywren_twitter
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
Lane Rettig
@lrettig
@AlexeyAkhunov this makes sense to me and I think it’s a valuable idea worth exploring. The piece that I still want to understand better is the implications upon trust - a “syncing” client is de facto trusting the peers that it’s receiving those headers and state diffs from, right? Since it’s not running every transaction itself. In this respect is it a bit like a light client protocol?
If so, what is the “full client” analogue here — is that the “archaeology/analysis” client?
ledgerwatch
@AlexeyAkhunov
@lrettig When you sync backwards from some point, you are trusting peers as much as you are trusting them when you are doing fast-sync on geth. It is lower level of trust than of light client, because light client does not download a snapshot of state to verify that it hashes to the the block's state root. In others, if fast sync and warp sync is OK for you, this proposed method is not any worse
ledgerwatch
@AlexeyAkhunov
Vitalik has suggested a solution to the hoarding and Dark Rent, which I think would work: https://ethereum-magicians.org/t/state-rent-proposal-update-and-dark-rent-markets/2202/21
Martin Holst Swende
@holiman
Looks like gangnam got stuck at epoch transition http://boot.gangnam.ethdevops.io/
Noel Maersk
@veox
If, say, there's an issue in the GPU miner software, then the sole GPU miner would've fallen off, and the symptoms would've looked as currently.
Martin Holst Swende
@holiman
Yup
matrixbot
@matrixbot
Noel Maersk FTR, since my last message, matrix shows two more messages since my last (other than Martin's "Yup").
Noel Maersk Peter, did you find the docker image and delete your message?..
Noel Maersk (Ah! Gitter "delete" action shows nothing in matrix. This noise, disregard.)
Peter Salanki
@salanki
I realized it was super easy to build the image by just cloning the branch so I deleted it
Martin Holst Swende
@holiman
I've also posted a gist earlier that has all relevant info in it (passwords, docker image, bootnodes etc)
Ghost
@ghost~5bf74ce8d73408ce4fafd49f
캡처.PNG
Maybe this will be a problem?
Noel Maersk
@veox
Non-issue. Answered on bug tracker.
Peter Salanki
@salanki
@holiman
I was looking for a Parity docker, got the Geth docker from your gist
Noel Maersk
@veox
Gangnam has stalled again (last block #43,021 2 hours ago). Likely the GPU miner simply went offline.
Greg Colvin
@gcolvin

A little dated, but still relevant…

https://medium.com/@FEhrsam/funding-the-evolution-of-blockchains-87d160988481

The lack of incentives to work on core protocols is reflected in the large number of people working on Etheruem tokens vs. the small number working on Ethereum itself. Launching a new token has made many millionaires in the last 8 months, whether on paper or liquid. Meanwhile, if you contribute to the core Ethereum codebase at best you 1) own a bunch of ETH personally and the price of them goes up a bit or 2) need to join the Ethereum Foundation and get paid some amount that wouldn’t match the economics of a successful token launch. As a result, Ethereum is starting to suffer from a tragedy of the commons problem: while lots of people own ETH and would benefit from Ethereum improving, the economic reward for any single individual improving it is low.

So it’s not surprising these massively valuable blockchains don’t have many people working on them. Despite being worth over $30bn and $65bn, there are only 15 meaningful contributors to Ethereum and Bitcoin respectively, and the rate of contribution isn’t going up much with their rise in popularity.

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jamie> I was considering some steps toward organizing a community gift for everyone working on 1.x improvements (a 2.0 gift could be organized later as this is further out). I understand that these efforts are something many are compensated for, but it would be fun for everyone to contribute to, and address a bit of the "tragedy of the commons" for those who are working on a voluntary basis.
<Jamie> Perhaps the participants directly involved in the work could vote on each others' gift allocation based on their impressions of contribution levels and financial need. This is how Munger Tolles & Olson allocates partner compensation. https: //www.forbes.com/sites/davidparnell/2017/02/07/brad-brian-munger-tolles-culture-egalitarianism-ownership/#213bce8d42ee
Mudit Gupta
@maxsam4
What is the current structure of the Accounts object? I suppose it has fields like address, code etc. I searched around a bit but couldn't find the exact structure in any docs. Any help will be appreciated, thanks.
Roy
@Shammah
Aside from monetary reasons, Ethereum core development is also much harder to get into. The research is highly academic yet also fragmented. I believe this is also why Vitalik asked for resource material feedback on Reddit (https://old.reddit.com/r/ethereum/comments/a6e0au/request_for_public_feedback_how_well_organized/). I feel that by the time I finally understand some core aspect, it's already been superseded. This is partly why I decided to focus on Web3 libraries development instead, which is much more accessible. I'll eagerly await some sort of continuously updated 'official university' of some kind (perhaps from ConsenSys, or the foundation?), instead of hopping from blog to blog, reading multiple forums and various books such as Andreas'.
Mudit Gupta
@maxsam4
Some architecture diagrams of go ethereum or perhaps a video of someone going over the architecture will greatly help Imo. Otherwise, it will just take hours and hours for a new programmer to start contributing (which, as everyone can see, not many are willing to do).
also, is there any more documentation on data structures available than https://github.com/ethereum/wiki/wiki/Patricia-Tree#tries-in-ethereum ?
Mudit Gupta
@maxsam4
It has what i was looking for but I wanna read more :)
Martin Holst Swende
@holiman
I don't want to sound flippant, but read the code for go-ethereum if you want to learn the details about go-ethereum. Docs about implementation internals have a tendency to rot fast. Docs about structures like patricia trees are great, but for a lot of things, the code will always be the best reference. It will take hours and hours to grasp it all, but we try to flag 'good-first-ticket's to help on-board new devs. And the geth discord server is better suited for general geth-discussion
Mudit Gupta
@maxsam4
I am not requesting detailed docs about the implementation. Just a 30 min video walkthrough maybe that says what is where. It will probably still stay relevant for months even if the code changes. I doubt the whole architecture changes every month. I know vitalik was looking for feedback around docs so here is my feedback as someone trying to contribute more during their free time. I am talking about go eth here as it is the official implementation. Not everyone wants to contribute in research alone. I don't want to just pick issues and solve them, I want to get the feel of the code first. I want to learn new things while doing that. I need to enjoy something if I am going to do it for free. I am just not ready enough to do chores that I don't enjoy doing without any gains. I know my request might be unreasonable but it's just my thought process, don't take it any negative way. Maybe other devs feel some other way. Anyway, I was here to learn more about generic data structures (Patricia trees) that I beleive are common among all implementation. I am not interested in tech details of how something was implemented but the overall design and perhaps rationale behind that design. To be completely honest, I was looking into why EIP 170 added contract size limit and how we can solve that problem by doing something else. That led me to EIP channel as I thought that was a better place to discuss pre-eip research but I was redirected here. Once here, I read a couple of posts above and thought it might be a good idea to give my feedback as well.
Mudit Gupta
@maxsam4
I guess Issues in the EIP repo is a better place for that discussion. ethereum/EIPs#1662 Any feedback will be appreciated, thanks.
ledgerwatch
@AlexeyAkhunov
@maxsam4 This is an interesting problem and I have not given it enough thought before. Looks like solution to quadratic vulnerability implemented in EIP 170 is very crude indeed, but the restriction can be overcome by using DELEGATECALL proxies, as you noted. I looked at your proposal to charge CALL, DELEGATECALL etc. proportional to the size of the code, and I think it might also not be satisfactory, because it still be preferable to split large contracts up into pieces of 24k bytes, to not pay the extra fees at each call. I believe that the satisfactory solution requires deeper investigation of the problem, and perhaps more fundamental change of how code of contracts is represented and accessed
ledgerwatch
@AlexeyAkhunov
Essentially, you can imagine that at the moment, codes of contracts in Ethereum is kind of split in slots (pages) of 24k. Cost of accessing one slot/page is the unit of granularity - you cannot pay less. So if you want to utilise more slots/pages, you need to built it up as a tree, and use CALL/DELEGATECALL between them, because in EVM contracts do not have "dispatch" (that makes me smile a bit because of this article we have been discussing, which has a lot of mentioning of the word "dispatch": https://ethereum-magicians.org/t/article-the-evm-is-fundamentally-unsafe/2219)
so you have to make your own dispatch :)
Mudit Gupta
@maxsam4
@AlexeyAkhunov Thank you for your feedback. I agree that what I proposed is also not optimal but to me it seems like a better solution to a problem that is not serious enough to warrant deep research just yet (maybe it is, I don' know). I have worked around the limits by using dispatch systems for increased code size and upgradability but they have their limits. I even wrote an article about them a few months back :) Dispatching costs more gas than direct call, reduces code readability, increases complexity.
A lot of problems with delegate calls can be resolved if solc allowed to compile empty functions so that the output had the ABI of functions that don't exactly exist in the smart contract but can be accessed any way via delegate call in the fallback function. Anyway, having a larger contract size will be a good change imo. Specially as gas limit is probably gonna increase soon.
ledgerwatch
@AlexeyAkhunov
Can you share a link to your article, please?
Not exactly about dispatchers but the master slave technique can be used as a dispatcher.
ledgerwatch
@AlexeyAkhunov
I think a good compiler can totally make this problem almost invisible, by creating a multi-proxy that dispatches call to multiple implementations. Though, of course, it would split out many contracts from one contract {} declaration, and deployment is a bit trickly (you would need to deploy all the pieces and then wire them together). CREATE2 deterministic addresses can help remove the need of wiring by deploying via factories though
Mudit Gupta
@maxsam4
Most of it can be done manually as well but the story does not stop there. Splitting into multiple contracts has problems like dApp devs have to switch ABIs for making calls. They can obviously use a 'fake' ABI but that shouldn't be needed. Also, no matter how much we want to avoid it but in real life people want to see the contract verified on Etherscan. It can not be done with dispatchers unless solc produces combined ABI.
Also, dispatchers will always be expensive as they will copy all the parameters from calldata to memory to make a delegate call. Normal external functions can just access the required parameters from the calldata. Not a big issue though.
ledgerwatch
@AlexeyAkhunov
I think these are valuable remarks. Instead of turning this into a debate, it would be good to structure this into a high level proposal and get it discussed and refined, like we have been doing with the State Rent proposal. When you start thinking about this deeper and creating the structure, it might naturally lead you to the code. As alternatives I would suggest your approach with allowing larger contracts that cost more to call, and a status-quo approach with beefed up compilers.
Mudit Gupta
@maxsam4
Yeah, that makes sense. Thanks for all your feedback, much appreciated. I will create a better proposal over the weekend.
ledgerwatch
@AlexeyAkhunov
I am sure it will take some more thinking and a few more iterations. Also try to think how to best visualise it - I found that this makes proposals much more accessible
Nick Johnson
@Arachnid

A lot of problems with delegate calls can be resolved if solc allowed to compile empty functions so that the output had the ABI of functions that don't exactly exist in the smart contract but can be accessed any way via delegate call in the fallback function.

You don't need compiler support for this - just specify any JSON-ABI you want.

I really think that if you're having to shard your contract into multiple parts for size reasons, though, your contract is far too bulky and complex. Smart contracts need to be small and understandable to perform their stated purpose.
ledgerwatch
@AlexeyAkhunov
@maxsam4 Actually, now I realised what I think the complaint was. Solidity does not generate the ABI you want when it compiles your proxy contract. But you can easily produce that ABI by combining ABIs of individual pieces. It looks to me the the problem is mostly with the difficulty to "verify contract on etherscan", right?
If I am right, then the problem can be solved on etherscan's side - it should be possible to attach whatever ABI to a "verified" smart contract, and not just used the one produced by Solidity. Because ABI is concerned not with compilation or correspondence b/w source code and binary, but with how users are going to call the contract. As @Arachnid noted, unless users refuse to use any ABI but the one showed on etherscan, the client app can use whatever ABI is required
Brian Cloutier
@lithp
A new version of the tests repo has just been tagged and published. There are a lot of new EXTCODEHASH tests which you might find useful.
Nick Johnson
@Arachnid
@AlexeyAkhunov The problem with that is that Etherscan would not be able to verify which ABI was "correct".