RE: An EOS Smart Contract for Block Producer Information

You are viewing a single comment's thread from:

An EOS Smart Contract for Block Producer Information

in eos •  5 months ago

I didn't see this conversations, but my opinion is that this contract isn't for node discovery.

Node discovery itself shouldn't even be on chain - since you'd need to connect to the chain to even access that data. It's a bit redundant, and if you're already connected, why would you need to discover more nodes?

This contract itself I feel is just about publishing the bp.json data on-chain - so that way the many wallets and web apps who need this information don't have to scrape 100's of websites.

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

I agree scraping 100's of websites doesn't make sense, but the pushback I'm getting from my team relates to the lack of a clear standard and the potential to have to support every backward compatible solution we introduce from here until whenever. If more people use this, will they also continue to support the website based bp.json file? If a full standard is developed in the future which puts this data directly into tables instead of as json, will that then be a third approach (with two legacy approaches to support)? That, I think, is the primary pushback I'm hearing from my team. A desire to plan out good specifications first, before introducing temporary solutions which will then need to be supported in order to not break applications which start to rely on them.

Unless we think the bp.json approach (both on the web and stored on EOS) is the solution the EOS community should be using for quite some time? I mostly agree with you that this is a good improvement on what is being done now, but I'm doing my best to relay concerns my team has to hopefully find some common ground. Maybe it's okay that app developers just have to change things as older methods go away naturally, but I think some prefer more structured, planned approaches and assurances that when we introduce a new approach, we've thought through if this is the best solution for the problem we're solving.

If this isn't for node discovery, then the current bp.json hosted on websites were were provided via listproducers still seems to be needed. If that's the case, is this data duplication?


This solution is both backwards compatible and forwards compatible. Nothing needs to change from a validator or info collectors' perspective aside from, instead of retrieving the data from 100's of websites, they only need to grab it from the blockchain in one call. There's no "legacy" support needed, so that makes zero sense, as the standard has not changed -- only the location of storing it. App developers do not need to change anything with regards to parsing the data.

I genuinely can't understand why you want to push back against storing this information on-chain. Why wait? Why do you want to keep using unverifiable websites? This is completely unlike you, so I'm curious what the real agenda is with that. Is it because your team spent time developing tools to scrape websites, and that work is about to be outdated? If that's the reason, then honestly, you need to really think if that's best for the EOS network or what your true intentions are.


No, it has nothing to do with anything we've built at all. I only want what's best for EOS.

I completely agree storing on chain makes more sense than storing on individual websites for a number of reasons. Ask @jesta to share the chat I had with him yesterday for more details. I'm kind of stuck in the middle a bit because I agree what you are doing is a worthwhile improvement, but I'm working through concerns of my own team, so I'm bringing those concerns as questions to you (even if they aren't ones I personally, passionately care much about).

I've spent way too much time arguing both sides of this (it really has become a bike shed). I'm happy to put our data on there and plan to do so (even if some on my team aren't excited about the idea). I think they prefer going from bp.json on websites straight to a well-defined, on chain standard. If app developers switch locations from website to onchain, that is a coding change which they will have to make and if they are already making that change, then the thinking here is should think about if there's a better, well-designed standard and on-chain approach beyond just a blob of json. Again, I'm not too concerned about it personally, but the idea is that some temporary fixes end up sticking around for a long time and then become difficult to remove in the future if too many systems are relying on the legacy approach. Removing the legacy approach later then breaks those applications. If we can void adding something we know will be a legacy approach soon, that's a good thing. It might be best to do it right the first time instead of having an intermediary approach. Unless we think this JSON is the best way to do it?

Maybe Michael Yates, You, Aaron, and myself can jump on a call soon to work out a standard we can propose to the community so we don't end up supporting two things on chain and instead only have one thing on chain. If we think storing this data as json on chain is the best solution and what we will do so for years to come, then it's great and we can just use this. If we think there's a better way to do it within EOS, maybe we can come up with that fairly quickly and do that instead.


I still don't understand it. This isn't a legacy thing. The "legacy format" is the current format, a JSON blob. This is what is on the websites right now, and this is what will be in the table.

There is NO CHANGE TO THE FORMAT. There is no legacy left behind. This is not a "temporary fix". Applications dependent on scraping websites can move over to this single blockchain call. There is no "legacy system" as the system is the same format, the only thing that has changed is the location of the data.

Why are you really pushing back against putting it on chain? The standard is probably never going to be well defined, and will be in flux for a long time -- and then, since that flux might never stop, we'll never move off using websites, while we squabble about standards forever.

When we move over to a standard with multiple tables (IF we can somehow fix the standard and get it out of flux), then we will have to change all tools for a format change. This format change can come later, because, once again. There is no format change with this contract. Only a data location change to on-chain.
Validation tools do not require any format changes! It only gets rid of the need for website scraping tools!

It's time we actualize "Blocks or it didn't happen".