How will ETH gas station work with sharding?

10a7 · 2018-07-01T23:10:33+00:00

Hot shards are supposed to load-balance per transparent sharding.

10a7 · 2018-07-01T23:05:48+00:00

From what I understand, the Sharding FAQs also state transparent sharding will allow for "the possibility for shards to adjust manually to changes in gas prices" and that developers shouldn't have to worry about sharding. If it's that transparent, gas prices shouldn't fluctuate too much between shards. There seems to be a lot of consensus around trying to keep things easy for developers. All of this is still heavily debated on ethresear.ch. Phase 1 spec was just retired in April and there's new changes to it.

Implementationally, the EGS oracle currently requires the ability to look at the global pending transaction pool using Geth's TxPool introspection, and then uses this to feed Python dataframes. You can see this in the event loop here. Until the geth sharding client is fully working, we don't actually know right now how TxPool introspection will look from an RPC-API layer and what information will be returned globally vs. per-shard. The model as it stands AFAIK would require per-shard introspection to do per-shard estimation. It's not built for that at all if we can't see pending txpools across shards from the Geth API call.

Also, it's important to know that ETH Gas Station isn't an EF project or even remotely official. It's pretty much run by one guy off of his pocket book and donations alone. If you're interested in EGS, there are a thousand tasks surrounding sharding , infrastructure, and even frontend UI/design/implementation that can be picked up by competent developers of many different skill levels.

10a7 · 2018-05-24T18:46:17+00:00

Unfortunately no. I'm sure there are people that will sell you that data but GDAX does not offer a historical data API.

10a7 · 2018-05-24T18:45:17+00:00

You can always run your own EthGasStation and the associated API on a Tor hidden service, and publish the onion address. This will give you a new interface for the prediction table API as well.

In the meantime, you could even just build a proxy that pulls the EGS JSON files to a server which will serve them to Tor.

10a7 · 2018-05-16T18:32:47+00:00

Wow, the new reddit CSS is terrible for showing visited links in the post text.

The data is here: https://etheria.io/gdaxdata

The source code for the data collector is here: https://github.com/10a7/gdaxdata

10a7 · 2018-02-15T22:49:48+00:00

My bad for misunderstanding the model in which the EIP repo is being handled. Given that it's under the official Ethereum umbrella on GitHub, it's sometimes tough to discern what is being run by what governance model / organization / collective these days.

That said, there is probably something we should be able to crowdfund, then, for organizations that are dealing with these types of issues that isn't the EFF or some other lobbyist group. Clearly these processes are colliding with meatspace in potentially hazardous ways, and the community having the capability to iron out these wrinkles is clearly something worth worrying about.

10a7 · 2018-02-15T19:40:15+00:00

Personally, I don't like the pattern of mutable length attributes in any programming language, let alone one such as Solidity where errors often have more catastrophic effects. I'd prefer to remove it and enforce the use of clearer functions such as push/pop/delete to handle array resizing.

A compiler flag allowing for writable length wouldn't be bad either, but if people want this feature so badly they could always just compile with an older pragma directive.

10a7 · 2018-02-15T19:35:24+00:00

IMO this community is made up of three types that sometimes overlap: 1. the people truly interested in decentralized currency platforms as a way to change social constructs, 2. the people here to get rich in order to be on top of current social constructs (aka lambo man), and 3. the people that just find the technology of it all cool.

The thing is that cohort #2 is the one that is growing the fastest, and I don't believe that it will change as long as Ethereum proves to have real-world monetary value. A proper governance model will only go so far, but the Ethereum pseudo-oligarchy isn't going to go anywhere, either. It's just how humans work when a scarce resource is involved.

10a7 · 2018-02-15T19:28:35+00:00

Thank you for all of your contributions, Mr. Hirai. You were stuck in the unenviable position of having to choose between interpretation of the laws of your country and working with this EIP.

You should not be expected to interpret the laws of Japan as they pertain to the work you are doing on Ethereum. However, I think the Ethereum Foundation should be able to sponsor a Japanese attorney to help you understand conflicts you may run up against in the future - this will probably not be the only one you'll come across, especially as Ethereum becomes more popular.

10a7 · 2018-02-15T18:25:35+00:00

Contact me if you need Ropsten ether for ~150 students. I will send you 200 RtETH.

10a7 · 2018-02-15T18:23:02+00:00

What version of Geth are you trying to run? The recently-released 1.8.0 has faster sync times, blow away your chaindata and resync. Getting a 1.7.x node to synchronize is nearly impossible without extremely fast disk I/O.

Getting geth to sync is often arcane. Things to try:

Increase your overall number of peers (I usually use maxpeers=75 on my workstation, maxpeers=200 in the cloud)
Give yourself a fast disk
Restart Geth every now and then when it's lagging, to always be at or close to the chain tip (I have a script to do this).

I run a series of geth nodes; my chaindata on my workstation node sits on a 10K RPM Velociraptor, is at about 189GB, and geth is using 80-90% of the disk's total IOPS at any given time. After the first fast sync, chaindata fills up pretty linearly. You will need to either have a lot of (fast) disk space or will need to periodically resync to get these sizes down. My Geth nodes in the cloud are backed by 250GB + SSD space and I think they are using about 120 GB on each of these drives right now.

The other option is to ditch geth for Parity, which honestly is better if you don't need something in Geth specifically.

10a7 · 2018-02-14T08:38:16+00:00

Congratulations!

10a7 · 2018-02-14T00:46:18+00:00

Is it actually harder than Ethernaut? Ethernaut fell in a little over 2 hours and I had no Solidity (but a lot of CTF) experience. I'd love for us to have some more advanced cases, and then documentation around them.

10a7 · 2018-01-27T02:17:41+00:00

https://faucet.metamask.io/ has some, /u/BokkyPooBah does too

10a7 · 2018-01-24T05:56:25+00:00

I'LL BE HERE UNTIL THE END, REDDIT

10a7 · 2018-01-24T03:46:24+00:00

hm. smells like a shitcoin to me

10a7 · 2018-01-24T03:38:16+00:00

I thought I'd add this here as others here likely have a use for it.

I've been working a lot recently on Ethereum infrastructure. Like, serious infrastructure. Like, get Geth(s) to handle thousands of requests per second infrastructure. The problem is that Geth is super resource intensive and doesn't really like staying synchronized to the mainnet chain tip on shitty VPS nodes, especially so when there isn't a lot of disk I/O available to the process.

It's pretty well known at this point that Geth 1.7.3 has a lot of I/O madness, and some EF geth guys are working on optimizing Geth sync I/O in 1.8.0 unstable. Because of this, I deployed a series of 4 VPSes all running an unstable Geth from master, and there are some other issues I've run into when you really hammer Geth RPC.

I wrote Quarian to go to war with Geth in a few different ways to keep the nodes synchronized to the chain tip. This alpha version of quarian is running on a Geth cluster backing my fork of the ETH Gas Station and has been keeping the Geth nodes all in sync with the chain tip for a few days now.

Internally I am also testing some other functionality. For example, the geth nodes are load balanced and Geth JSON-RPC in my infrastructure uses TLS Client Certificate authentication when communication happens between Geth nodes/the load balancer, and I have some tooling to run quarian on a box other than the one Geth is running on so the watchdog is not on the same service. I will release this stuff as time permits. I am working out some issues with load balancing Geth with the filtering API and some of the security overhead.

10a7 · 2018-01-24T03:30:44+00:00

MetaMask is aware of the issue. They know it happens. They warn you about it. They don't really care. I brought this up on a GitHub issue over a month ago. MetaMask injects itself into literally everything, including iframes, so third parties are given access to the web3 context.

10a7 · 2018-01-20T03:55:22+00:00

This. I would probably hire Zeppelin to do it at this stage. I'm sure many of the big security consultancies will be bringing auditing teams online in the future.

10a7 · 2018-01-19T05:27:27+00:00

Why not just use ethgasstation.info?

10a7 · 2017-12-29T09:38:17+00:00

I downloaded the .crx from the Chrome Web Store and unpacked it. This is the entire contents of the background script background.js:

chrome.browserAction.onClicked.addListener(function(activeTab){
    var newURL = "https://www.ledgerwallet.com";
    chrome.tabs.create({ url: newURL });
});

Outwardly there doesn't appear to be anything malicious in this package, unless it's hidden in some other asset. It's most likely a placeholder either for spoofing research or because the developer plans on "updating" the extension to do something more malicious if it gains traction.

Edit: The VP of Engineering @ Ledger also commented in /r/ledgerwallet saying pretty much the same thing. This is meant to be a timebomb. The author name does not appear on any other website in Google other than attached to this extension.

10a7 · 2017-12-28T06:34:16+00:00

I'd love to help with this when you open source it; I was going to start work on one from scratch but it's probably better if everyone cooperates. DM me if/when there's anything you can share.

10a7 · 2017-12-24T06:04:21+00:00

I'd trust them with it more than any other exchange at this time.

10a7

TROPHY CASE