EOS BlockPros Chat Summary for May 3 - 9  2018

Discussions on Dawn 4.0

*Please note. A comment in the “Con” column can be con, neutral OR a question. It's less about an absolute stance, and more about the back and forth of the dialogue.

New Market-Based RAM Allocation Model



Yves La Rose - EOS Nation

I've re-read over and over and one of the most interesting lines to me is " If annual trading volume of RAM equals the token supply then 100% of all block producer rewards will be covered by the RAM market fees."


Very interesting with the new ram model... I will have to think about this and what it means.

Interesting that the fee involved potentially could pay the BPs fully.

Link - RAM allocation model

Kevin Rose - EOS New York,: Hey all, we collaborated with @YBNorml and the EOS Nation team to write out our thoughts on the RAM allocation model. Thank you to @GunnisonCap and @TheAwakenment for inspiring the discussion as well. https://steemit.com/eos/@eosnewyork/offsetting-the-costs-of-block-production-marginal-costs-trending-toward-zero-on-eos

@YBNorml please also post your link (spoiler alert - they are identical!)

        > Yves La Rose - EOS Nation: Hey all, interested in reading about how the EOSIS Dawn 4.0 RAM allocation model could trend the EOS network towards ZERO marginal cost? Co-written with @eosnewyork , inspired by conversations from @GunnisonCap and @TheAwakenment - thank you guys!


Rise of Inter-Blockchain-Communication




Same producers on all chains - to me this is the biggest mystery in this post (which probably is related to me misunderstanding some things previously...(?)).

I do see multiple potential issues with allowing different sets of producers on different IBC connected chains (for example when it comes to constitution and hoarding of inflation derived tokens), but I really liked the idea that token holders possibly could move their tokens between chains (without trading) and have their tokens generate inflation, voting rights and so forth on whichever chain they decide to live on.

It would have allowed inter-blockchain market forces to come into play and in my mind it would have lowered the risk of collusion between big players (since people could easily move to another chain) as well as made sure that we would have had "one token to rule them all". Would have made things very interesting...

Doesn't this promote having multiple chains where each chain has its own distribution of EOS tokens? Is this positive or negative? I don't know - we still need the 15% vote to activate each chain.

4. Backing out of multithreading because it is very complex (?). Probably a smart move to get everything as stable as possible. Hard to know how (and if) the market will react since it's been one of the major selling points for EOS. In my opinion priority should be to make things as simple and stable as possible.

I believe we won't need even 5k tps for quite some time so personally I have no problem with this change.

I however do not understand what: "... upgrading from single-threaded to multi-threaded execution is to launch a new chain with multi-threaded support run by the same block producers and staking the same native tokens" means. Does it mean we will use the same tokens (on the new chain?), or a cloning of the token supply (including what is currently staked and how the votes are cast)?


A new sidechain would be part of the main EOS net if it shares the same set of BPs, also I think that for them to launch a new sidechain it isn't required 15% of approval... I could be wrong in that last bit, but basically we have one chain acting as a single execution thread and BPs (must be the same) can launch sidechains at will. That's how I outlined it in my head anyways. So in that scenario there is no need to worry about constitutional hijacking in the sidechains

Craig Murray - EOS BlockSmith

Yeah, the sidechain news is exactly what I was expecting... main chain BPs run the sidechain, which has no inflation or governance of it's own, but acts as a sub-chain to the main chain and can be spun up whenever the main-chain runs out of ram

So powerful is this sidechain approach they are basically dumping parallel processing.... parallelization does not get you more ram and is therefore quite limited in terms of its ability to scale. At that point with this sidechain approach the only limit to a dapp would be that you can only have so much ram on a given sidechain. If your ram requirements are bigger than that, and you have to run your application across multiple sidechains, you must break your data into chunks across sidechains because there will be no way to share RAM across chains. But that point ignored, you have essentially infinite scale

Craig Murray - EOS BlockSmith

ok so you want to create a new sidechain. You need 21 BP at least to create the network in the first place, right? How do you elect them if there are no tokens on your network? How do you move tokens to your network if you don't have any BPs yet? I think the dawn 4.0 sidechain solution is exactly what we need. I'm very pleased, personally. Simple, elegant, massively scalable

Roger Davies - EOSUK.io

When a RAM trade takes place and the 1% fee is charged, where does the 1% fee actually go? Also, how do peoples actually buy and sell this RAM? Do they have to use a command line at the moment and we and/or other people will eventually create web interfaces to those commands?


They will probably be locked up in smart contracts for atomic swapping to other sidechains. The inflation on the main chain will thus be 1 Billion EOS * 5%

David P - EOS42

It appears to be a transaction fee applied to avoid misuse of RAM. If we look at how transaction fees are applied elsewhere, logically it is burned hence the counterbalancing deflationary aspect that ‘offsets’ (potentially entirely) BP 1% inflation.

Dean Zaremba

Man, hate to burst bubble, but just looks like shell game to me. The ram is still a 1% fee. The money has to come from somewhere. A fee for ram or inflation of eos. Put it in whatever shell you want. If you want to call the bps inflationless, go for it, but there is still 1% ram fee.

Kevin Rose - EOS New York

To reserve RAM, not to broadcast transactions

Rick Schlesinger - EOS New York

The fees offset the inflation - that's the key here, so you're getting something that looks "inflation-less" reducing marginal cost


I like this feature since it decreases inflation with the increase of RAM volume trading, given the trade fees are going to be burned. This may in fact lead to overall deflation (= decrease of EoS tokens) as soon as the RAM trade volume sufficiently exceeds the EOS token supply.

Upgrade DPOS Last Irreversible Block Algorithm




If I understand it correctly I really like the change to the LIB-algorithm.

I believe that the problem that this fix solves has happened in the community testnet already. So even if that is mostly speculation on my part - and even if it probably wouldn't happen on a live blockchain, I'm glad to see it removed as a potential problem (we fixed whatever happened by re-syncing a couple of our nodes and it was during a time of flux (...and while we had some other now known and addressed bugs in the software).

Looking back at it I wish we had investigated it a lot more closely.)

Name Squatting




Name squatting. Forcing us to have 12 characters in our "easily readable account names"... I don't like this. But I understand the reasons behind it. Maybe all accounts that has had their ERC20 tokens for longer than 2 months should be allowed to get one shorter name each? (Trying to make sure people don't split their tokens before launch to be allowed to buy names)

Refined Producer Pay Model - Standby Bps



Craig Murray - EOS BlockSmith

Wow, super interesting what they are doing with standbys. Dawn 4.0 is awesome

Rob Finch - Cypherglass.com

There are 21 active block producers and any number of standby producers. The top 21 divide up the 0.25% per-block rewards proportional to the number of blocks each one producers. All block producer candidates (including the top 21) also divide up the .75% per-vote rewards budget proportional to the total number of votes they receive. They can claim their share of the per-vote rewards at most once-per-day. In order to claim their share they must qualify for at least 100 tokens/day. Producers candidates who do not qualify for at least 100 tokens/day on a per-vote basis will receive nothing.

Sam Sapoznick - EOS Supporter

Relieved to hear that there is no upper limit on standbys. I was a bit concerned with rumors / proposals for only 40-70 standbys.

Kevin Rose - EOS New York

Craig Murray - EOS BlockSmith

Marshall - SaltBlock


Craig Murray - EOS BlockSmith

If there are a bunch of really fat whales at the top, there will be less standbys... the more spread out the votes are, the more standbys there will be

Daniel EOSMetal

Though, this new model has new potential concerns... Exactly, was about to comment on whales

Craig Murray - EOS BlockSmith,

Wow, ok well, I have NO IDEA how many standbys there will be now... so that's exciting, and equally terrifying as a BP candidate

Syed | EOS Cafe / Calgary

Quite exciting to have so many reserve block producers


Pareto says a lot less bpc. From a network perspective, I like this changes. 70 bpc sounds reasonable

Refined Producer Pay Model – Pay per vote rewards



Rhett Oudkerk Pool -EOS Amsterdam

I do not understand why they keep pay connected to "per vote rewards" and be concerned for wealthy individuals. Why not simply equal pay. Producing blocks is producing blocks

Kevin Wilcox - EOS Go,

They want BPs continually working for votes

Rhett Oudkerk Pool -EOS Amsterdam

It only incentivise the whales

Sharif Bouktila - EOS Dublin

I've been mulling over the BP rewards for the weekend. Does anyone else see an issue with the allocation of the .75% based on votes? To me if the guys at the top receive the majority of funds the weaker / lower voted BPs won't have resources to scale and the entire network will suffer.

Craig Murray - EOS BlockSmith

If 100 EOS a day is not enough to maintain scale, then yes that may be a problem

Refined Producer Pay Model – Bids



Kevin Rose - EOS New York

Interesting that bids are out. Bids protected against downward token price movement.

Craig Murray - EOS BlockSmith

Yup, bids are out... that is kind of interesting. So much for controlling inflation with bids I guess. :)

Sam Sapoznick - EOS Supporter

Eliminates any possibility of BPs attempting to collude the inflation % upwards. Still digesting this new pay model.

David P - EOS42

Suggests small and lean is the best approach

Refined Producer Pay Model – No fiat peg



Sam Sapoznick - EOS Supporter

Yes, I noted there's no attempt to fiat-peg here, this speaks of an optimism about EOS public chain specifically & the crypto markets generally. It may turn out to be justified.

Yves La Rose - EOS Nation

That works for me. Fiat pegged was very complex if we wanted to factor in geographical variables

Sam Sapoznick - EOS Supporter

Right, good point, unworkable probably. A rat's nest.

Yves La Rose - EOS Nation

I mean, there are pros and cons to both of course - but knowing I now base my models off of token price helps me plan accordingly. It's also market efficiency driven, which I support

Sam Sapoznick - EOS Supporter

I now see & agree with the wisdom of sticking to pure token compensation, ignoring fiat adjustments. The smart BPs will set aside $$ from good times to ride through possible bear markets of whatever length. Plus have org & hardware down-scaling plans in place to cut costs if needed. In X years the chain can always develop & vote in fiat pegging if it wants it. Way too complex to deal with now.

Refined Producer Pay Model – No more cliff



David P - EOS42

What I like most about these changes to BP block rewards is that it flattens potentially the “premier league” top 21 and cliff edge thereafter and places a far, far higher emphasis on number of votes received.

        This rightly recognising the importance of standby producers and their other work likely to be going on. I do think it is realistic that the top 50 or so BP’s will pick up a huge percentage of the votes, which will lead to an interesting commercial market forces dynamic defining the absolute number of reserve producers.

Refined Producer Pay Model – 3.33% Ceiling



Sam Sapoznick - EOS Supporter

I'm re-reading the Medium.com post. There's a 3.33% ceiling? This is sounding better all the time.

Rob Finch - Cypherglass.com

Does that 318 include the % of the 20,000 or is that the flat fee the top 21 get? I don’t see anything about a ceiling in the post. Very curious about this.

Pete BlockMatrix

Assuming the 21 BPs produce the same number of blocks, they would each receive around 318, plus their proportion of the vote rewards on top

Sam Sapoznick - EOS Supporter

Yes. I'm still not clear on certain basics. If someone locks 100 EOS for voting, do they have to rank exactly 30 BPs? Or can they choose to just allocate votes to 1 (or 5, or 7, or n<31) BPs?

It sounds like.. from Thomas's note above re: 3.33% cap -- that one must vote for 30 BPs.

Yves La Rose - EOS Nation

I think it's as many as 30, as low as 1

Sam Sapoznick - EOS Supporter

If there is a 3.33% voting (or vote-share-of-rewards) cap per BP that would seem to go a long ways towards helping to keep the playing field level. Maybe this hints that voting mechanics have changed to be "must choose the top *thirty* block producers".

Yves La Rose - EOS Nation

I for one am happy we've got something set and can now plan accordingly. I prefer this model personally as it puts more responsibility on each BP. Market economics. Definitely need to have better business management practices and be very efficient. In a not so subtle way, Dan is telling BPs, get your act together, we're not going to subsidize BPs just for the hell of it

Rick Schlesinger - EOS New York

It will drive BPs to operate pretty lean and in lower cost regions. Very much so. And my guess is that we'll likely end up with less than 80 total BPs.

Tim Weston

I like how it makes it less lucrative for the big guys hoping to have 10% of total votes. If anything, we might see some of the big exchanges and mining pools revoke their candidacy

Refined Producer Pay Model – 1% Fixed



David P - EOS42

I couldn’t agree more strongly with Rick’s point. I’m just going to repost a segment of what I have said on Gov about this as it is relevant too:

        It’s a great system, my sole concern being it has kept the 1% as fixed. That’s the only crude aspect economically of a clever adaptation to the system. 1% always presumes we all know the required level will always be sufficient. A network that expands will see inevitable heavy investment infrastructure to support it pushing up the cost base and required token price for a BP.

        They will therefore be exposed as a systematic risk for all BP’s to wider macroeconomic shocks in the token price as we have seen before.

        Luke Stokes has given a vivid example of Steem witnesses operating at a loss through periods after a token price crash. I am sure nobody wants to see that. I do not see why this vulnerability is not there now we have a fixed percentage, however the vast 4% annual worker proposal fund ought to enable support in such a time - unless the community doesn’t appreciate its own best interests.

        Overall it’s a positive amendment, I hope it makes those throwing their hat into the ring for vast sums now appreciate this is about supporting EOS above “when lambo”.

Luis Herranz

I have another concern with the new model about scaling and a market-wide crash because BPs rewards are hard-linked (1% inflation) to the EOS token price.

        People here is suggesting that the BPs should be prepared to downscale, but that doesn't seem plausible to me. If EOS has gotten to a certain scaling point, it means most of those resources are already being used by dapps or BPs would have not scaled to that point.

        Is EOS capacity going to be dependent on token price? Are dApp developers (and their users) going to suffer the consequences of a token price fall due to the downscale?

        It doesn't seem like a smart move. At least in the old model BPs had the ability to recast their vote and get a bigger % of the inflation to compensate for token volatility…

I guess it can work like this:

1. Token price goes down due to market-wide crash. This means speculators are selling, but not Dapp developers.

2. BPs can't afford the current systems and have to downscale.

3. Dapp developers have less resources allocated and need more tokens to keep their apps working, so they start buying from speculators.

        In this scenario tokens would move from speculators to Dapp developers, which is good for EOS as more tokens are used to actually use the blockchain

Request: Clarification

Rob Finch – Cypherglass.com: Agreed. Would be helpful to see a single blog post dedicated to clarifying the new compensation structure @thomasbcox

        > Tim Weston: More clarification needs to be made around preference voting in particular

Request - Mandatory casting of 30 votes

Dean Zaremba: Right, cap could actually be higher with 30 vote process than just one vote process. If the whales just exercise one vote for themselves, and the average joe, uses all 30 votes, and because they have 30, most will also vote for the whales. The end could be that the whales get more than 10-12%, which would be the normal pareto max in a 1 vote for all system. Ie, anyone that has skin in the game, will only cast one vote for themselves, and not cast their remaining 29 so they don’t dilute the pool. But the average voter with 30 votes, will surely say, I will use some of my votes on the whales, and some on the field. So the whales win big. Could be less than 50 total, including the 21 actives, that secure 0.5% of the total vote in this model. (unless casting all of your 30 votes was mandatory, and for 30 different BPs, then yes, the cap is 3.33%)

        > Tim Weston: +1 for making this mandatory!!

        > Dean Zaremba: To make it worse, if 10 whales, each cast 10 and only 10 of their 30 votes in an agreement to vote for each other...game over.

        > Syed | EOS Cafe / Calgary: That's a big risk for them. If that agreement comes to light in arbitration, all 10 whales have a lot at stake.

        > Dean Zaremba: Agreed, but why even set the rules up to temp them....

Concern - Voters due diligence abilities

Aaron Schnider - The Swarm – swarmeos.io: Is there any concern about voters even being capable of doing reasonable due diligence on 30+ candidates?

        > Rob Finch – Cypherglass.com: The problem with this is if a user only wants to vote for 5 BPs, the other 25 are going to be misinformed votes.

        > Tim Weston: It could force them, giving them better understanding of the total environment. Therefore creating a better overall decision.

        > Sam Sapoznick - EOS Supporter: I like the idea of requiring a minimum spread of votes. An optimal number might be 10? How does the math work out for that.

        > Dean Zaremba: I agree, vetting 30 BPs is tall order to ask the average coin holder.  And I agree, the optimal number of votes is probably less than 30 per, but I doubt that will change, this late in the game.

        > Rob Finch – Cypherglass.com: My thought exactly. If you require any more than 1 vote, you risk forcing people out of the system (too complex, too much DD required) or into the system (misinformed, clicking a random XX BPs to fill their quota of 30) and neither is good

        > Tim Weston: Maybe there is a more ideal number rather than 30

        > Aaron Schnider - The Swarm – swarmeos.io: If there's concerns about people voting based on geopolitical borders, it seems like this would push it further in that direction.

        > Rob Finch – Cypherglass.com: IMO when it comes to voting, simple is best. The more pop up boxes people see when voting, the less likely they are to actually convert and vote. If a user sees “Error: must select 30 BPs” a non-negligible % of people will stop right there and not vote.

        > Eric: Keep in mind that voters cannot keep track of too many BPs.

        > Aaron Schnider - The Swarm – swarmeos.io: This has been a concern of mine. Even 30 seems like a bit much to properly vet.

        > Craig Murray - EOS BlockSmith: Token holders have a huge responsibility. We'll hopefully see objective 3rd parties evaluating them and acting as vote proxies

Qualifying votes

Aaron Schnider - The Swarm – swarmeos.io: Right, it's a conundrum. My initial thought is minimizing the friction for voters, but what are the implications of actually qualifying votes in some way (if possible). Requiring all 30 votes, but also some other measure to ensure some amount of reasonable vetting. You'll have a smaller number of voters, but those votes would presumably have done their due diligence.

        > Tim Weston: Maybe if votes were descending weight i.e. from 1 – 30 so not all votes are equal. They vote 1 for their top and so on. There the weight of the 30th vote will be 1/30

        > Dean Zaremba: Weighting the votes would be mathematically viable, but to others points, adds complexity to a system that will work best with simplicity.

        >Aaron Schnider - The Swarm – swarmeos.io: For each lesser number of castable votes., more power is put in the hands of whales though, right?

        > Tim Weston: Correct. I guess its a balance of having informed votes that are simple to encourage mass voting, but at the same time spreading the power as far as possible. Maybe 21 is better number seeing as there needs to be 21 active producers to support the network

        > Rob Finch – Cypherglass.com: Thinking on this further, doesn’t forcing someone to vote XX times devalue their votes? If someone chooses to vote for 1 BP they think is best, they should be able to without devaluing the vote by 30x. The collective community will elect the total 21. It’s not up to each individual to vet and vote for their own 21.

        > Tim Weston: This why I think a weighted voting system would be more sufficient. They decrease in weighting from 1 - 30 (or 21, etc)

        > Aaron Schnider - The Swarm – swarmeos.io: Yah, unless you have a mechanism to remove voters who will cast uninformed votes (which I'm not sure I would support), I think you've gotta allow for 1-30 votes. But even then you may not get around geopolitical tribalism. Weighted voting is interesting though

        > Gilgamesh: This isn't new theory. Look up approval voting. Punishing people for approving more candidates makes it worse. I'd prefer it was 1-100s tbh, but I guess 30 limit keeps people in top 100 easier even if group unites against them. 1 vote is the absolute worst voting scheme. http://scorevoting.net/LoseAll http://scorevoting.net/BayRegsFig.html

Well, random I guess is worst lol

        > Luis Herranz: One way that could be solved is by giving each of the 30 votes a power of 1/30 instead of 1/X where X is the number of BPs a user is voting

Link - Updated revenue analysis

Mathieu Boulianne - EOS Canada: Guys, here is a revised version of the model we had initially built that reflects the latest changes announced last Friday. We are now using much flatter Pareto scenarios (where BP #1 has between 3.5% to 2.6% of votes). We adjusted for the 100 tokens threshold “Leaky Bucket Algo,” and the new reward distribution system. We would love to get your feedback on it! cc @thomasbcox  https://www.eoscanada.com/eos-block-producer-illustrative-revenue-analysis

Producer Vote Decay



Kevin Rose - EOS New York

Vote decay is every week now

Craig Murray - EOS BlockSmith

Yeah, and they are asking for a constitutional article making bot voting illegal. Dawn 4.0, for the win

Luis Herranz

Uhm... I didn't get this yet. Now vote staking is 3 days but votes are there for a year (with the decay). What happens if I unstake those tokens, do my votes disappear? And if they don't, I could transfer the tokens to a new account and vote again, couldn't I?

Josh Kauffman - EOS Canada

Here's a scenario. You have 100 tokens and you want to vote for BPs 1 2 3 and 4. You stake your tokens for the vote. After 1 week of being staked, their strength begins to decay. It decays (I believe) linearly over the course of a year until it hits %50 power 1 year after the initial staking. This is to encourage voters to reconfirm their vote often, rather than take a set it and forget it approach.

If you decide you want to transfer for your tokens to an exchange to sell off, or stake them for RAM now instead, you would unstake your tokens. Your votes would be relinquished (I'm fairly certain) immediately, but your tokens would be in a locked state for 3 days.

I haven't seen the question regarding staking for votes if the release of votes occurs right away, but it was asked for CPU and Dan had said that you lose your allocated resources right away and don't hold them for those 3 days of unstaking.


1. How is EOS protected against spam?

Josh Kauffman - EOS Canada: How is EOS protected against spam? https://www.eoscanada.com/en/blog/can-someone-spam-eos-network

2. Jobs

Denis Bobrov: Hello guys, just wanted to showcase recently created EOS jobs-related chat for developers & companies seeking for them:


3. Draft constitution summary

Josh Kauffman - EOS Canada: Been having trouble keeping up with all of the different Articles in the current draft of the Constitution? We've created a reference so that everyone can easily follow along. https://www.eoscanada.com/en/blog/summary-draft-constitution-eosio

4. DDOS mitigation

Charles H - EOS 42: As per a few mentions, here is the DDOS article. We will also be taking requests to to test other BPs DDOS solutions. All results will be kept confidential if you choose so. http://blog.eos42.io/ddos-mitigation/

5. EOS community hackathon

Sean X Anderson - sw/eden – eossweden: Here's a quick (75 second) video we put together for the upcoming Hac-til-Dawn. The best part was that I managed to get @xebb82 into the video - which was amazing considering his schedule... https://steemit.com/eos/@seanxa/hack-til-dawn-an-eos-community-hackathon