What are the problems with the EOS Mainnet?

[benobi]

This is a topic to discuss the current issues with the EOS Mainnet facing token holders, developers, block producers, and other community members. Everyone is invited to take part.

Please add your thoughts here and let’s have a discussion!

I was speaking with @lovejoy about it today and we thought it might be timely to start a discussion on this topic to find out what people think are the biggest issues facing EOS. The first Eden trial playoff is coming up and I hope that some of the issues we discuss here continue to be topics discussed in the groups during the playoff.

I searched the forums for the word “problem” and “issue” and I came back with very few results. That’s what made me want to start this thread as a place to host a real discussion about the issues we face as the EOS community.

First, I want to say how proud I am to be a part of the EOS community. EOS people are my favorite people in the blockchain industry. There are so many intelligent, giving, and kind people in EOS who are not “maximalists” who try to exclude others but instead, focus on inclusion and collaboration with other chains.

I’ve been involved with EOS since early 2018 - before the launch. I have run a Block Producer, collaborated with many BPs on projects, worked on the EOS Alliance / Foundation and I’ve built mobile apps that are “Powered by EOSIO.”

These are some of the issues I believe that are big issues facing the EOS Mainnet:

• Account creation for dapps
  It’s very expensive to create accounts for applications who want to offer free accounts to their users. Perhaps we need some official support for “lite accounts” that have limited functionality and can be a good starter account that is perhaps limited to a single app.

• On-Chain Resources are confusing
  Users should not have to care about RAM, CPU, and NET. This is very confusing to end users. Proton (a fork of EOS) actually has a pretty good system for this where apps pay for resources. Something similar should be done on EOS - I know that FirstAuth and PowerUp are useful, but they are still a barrier for new apps to figure out.

• Block Producers should be held accountable to standards
  Block Producers have a technical responsibility, but they also have a social and economic responsibility to the community. We need Block Producers who do more than run a single server to process transactions. We originally thought that BPs should support their communities with tools, events, developer support, running reliable history nodes and just in general - trying to make EOS the best place to build apps. That seems to be beyond the job description as running the chain is a multi-person full-time job. This is an opportunity for Eden!! Reliability is a big consideration. The top BPs may not score highly on the EOS Nation tool - but the chain is run super-reliably - look at this Aloha reliability tool. They have robust infrastructure but it’s not reflected in the scorecard. My concern is really with the standby BPs - we have way too many getting paid to do nothing. If they have no chance of reaching the top 21, they don’t even need to run a server and we would not know… Many BPs are getting paid to do below the minimum - just take a look at the scorecard that EOS Nation built. We have already lost many great Block Producer teams due to not being able to get paid (even as standby) though they provided incredible value to the mainnet. BlockMatrix is one of them, but there are many more who have left over the years. EDITED

• EOS has no website
  I know something is in the works, but as of the time of this writing - there is no website for EOS. Block.One has a site for developer resources, but EOS itself has no identity or source of contact and it’s so separated from B1, that it really needs a home where people can go to learn about EOS or where reporters can go to find real information.

• A super-simple EOS wallet
  I am a huge fan of Anchor and also Wombat - but I still think that an official mainnet wallet that supports just one chain and one account is needed for most users. Too many users contact me who are still trying to use old versions of Scatter which seem to be broken.

• Voter apathy
  The token holders don’t seem to care much about voting or engaging in governance. Some people may say this is a good thing, but myself and many others have created voting proxies to support Block Producers - especially those who are lower on the ranking - who are actively trying to do more than just sign transactions. We lost a lot of good proxies.

• Support from B1
  This is sort of the elephant in the room and a big part of discussions we have had for years - even before the launch. Block.One should be supporting EOS in more ways and being transparent and collaborative instead of hiring important community members and putting them into what seems to be an ivory tower.

• An EOS Foundation / Alliance
  EOS needs an entity that is inclusive and looking out for EOS itself - with resources to support the EOS ecosystem. We spent 3 years working on varioius iterations of this idea (EOS Alliance / Foundation / DAO). Special thanks to the extraordinary generosity of time and resources from @Brockpierce @Galiab @lukestokes and so many others who have worked with us that I could not find to tag here.

I am very excited about the potential of Eden and we are looking forward to what we can accomplish together as a community.

[themoneyteamgh]

I believe eoscommunity.org and eosio.support do a good job of introduction & teaching about EOS. A merger of some kind between these two with rolling updates & focus on ecosystem & new dapps usage/opportunities/tutorials would be ideal.

I agree that #EOS desperately needs simplified free account creation. Something like what #Telos has. How about making a proposal to use eosio.savings (or its equivalent) to fund & scale initiatives like the un-abusable free account creation greymass had in its anchor authenticators initial iOS release. Scaling free account creation & easy wallets ecosystem-wide should be one of the main priorities of EDEN.

Also
I shared an idea with a few eos figureheads on twitter. Posting it here, hoping something comes of it.

Been trying to get this to people like chaney or eos reddit mods.

I believe Governance & transparency needs to return to the forefront of #EOS and proxies are the best way to achieve this.

Colin leaving and the manner in which he did so unfortunately left a mark on the EOS image and was a blow to governance. However its created opportunity for other stronger proponents of EOS to step up.

I propose this;

Someone like you could setup an EOS voter proxy focused on publicly highlighting BP contributions to EOS & it’s ecosystem.

“ #EOS BP Contributions Roll Call #1
What have you done this month to make #EOS better?

I will delegate votes from my proxy “xxx” to BP’s who retweet & reply to this.

P.S : these will be prioritized.
BP’s running efficient bare metal infra + Uptime.
Tech, community tools/resources, UX focused contributions(e.g. supporting free account/txn’s initiatives like greymass FUEL)
Ecosystem/Educational/Promotional contributions. (E.g. support/recognition/USE of #EOS based Dapps like @novusphere & publications+advocates like @hodleos’s https://eosio.support/ / listing of #EOS tokens) “

Publish something like that on the 3rd week of every month, allowing the BP’s to reply during the week, then you judge based on the stated criteria and vote at the 1st week of the next month.

Ask the community to delegate their votes to your proxy if they support EOS transparency and ecosystem growth.

This way BP’s can make their voices heard publicly, voters are kept informed, & the world can see the transparent governance EOS enables first hand.

You could post the monthly roll call on here, twitter, VOICE &/or discussions.app and favor BP’s who reply via a forum.eoscommunity.org discussions.app or VOICE post in your voting decision.

We need to bring the conversations from closed telegram groups into the open and show the world what EOS is all about. Putting this idea out there for any staunch EOS supporters to implement as i’m unable to do so with consistency due to personal constraints.

You’re welcome to spread this idea far & wide.
I hope an EOS supporter with a louder audience(including the east) can get this going.

[NatPDeveloper]

Guaranteeing an EOSIO transaction has been a point of friction. Dfuse fixed this with their API; however many developers wish not to rely on a single service, even if it is open source.

We took a crack at it ourselves here: GitHub - liquidapps-io/eosio-push-guarantee: eosio blockchain transaction guarantee library

Would be great to see the community handle this for good. Though our library works, it needs more tweaking, and still requires the developer to handle duplicate trxs and other errors.

[aaron]

I’m just replying to what you’ve written in this individual post and I’ll start another one with what I perceive as problems that Eden could help address.

@benobi

Account creation for dapps
It’s very expensive to create accounts for applications who want to offer free accounts to their users. Perhaps we need some official support for “lite accounts” that have limited functionality and can be a good starter account that is perhaps limited to a single app.

The bare minimum account right now costs around 0.0577 EOS (~$0.60 USD at the time of this writing). It’s a barrier to entry for sure, and if we could have some sort of cheaper account that’d be a great alternative. The problem is that when we start talking about “lite accounts”, most of the conversations move in a direction where these account cannot support dapp usage and only supports token transfers.

If someone can propose a good solution here it’d be worth supporting - but so far that proposal doesn’t exist. For this to be a good topic/proposal for Eden, we should start with a small R&D phase where this topic is researched and reviewed by the community. If a viable solution emerges that meets the needs of both users and dapps, then a standard could be established around these new types of account and development could later be funded.

My personal thoughts here are currently that users themselves should pay for their account creation and make the onboarding process as simple as possible (from all starting points, including from an app). This is the direction we are heading with our stack.

@benobi

On-Chain Resources are confusing
Users should not have to care about RAM, CPU, and NET. This is very confusing to end users. Proton (a fork of EOS) actually has a pretty good system for this where apps pay for resources. Something similar should be done on EOS - I know that FirstAuth and PowerUp are useful, but they are still a barrier for new apps to figure out.

New apps shouldn’t have to figure it out either. All of this complexity can be handled in both the wallet and SDK layer, with neither the app or user themselves having to understand how resources work. This is possible today with the systems we have in place, we just need to put some priority to establishing standards around how it all works.

I’m really not trying to shill our efforts here - but the this (and account creation) have been our focus for months at this point. We are working towards solutions for both users and apps to remove all of the friction on these two points.

@benobi

A super-simple EOS wallet
I am a huge fan of Anchor and also Wombat - but I still think that an official mainnet wallet that supports just one chain and one account is needed for most users. Too many users contact me who are still trying to use old versions of Scatter which seem to be broken.

Why couldn’t Anchor (or even Wombat) be this? Scatter had a really good chance to be just that, but with their team efforts shifting to Ultra we lost a lot of momentum on that front, leaving many users in a bind.

@benobi

I am very excited about the potential of Eden and we are looking forward to what we can accomplish together as a community.

Agree , it’s an exciting time to be a part of this community!

[freepizza95]

Thx benobi for this post it’s very well needed.
I think it would be great that we create a topic for each of the issues we feel are important to solve
One issue I see is also media coverage and reputation, but I feel like it has to come after solving some of the issues you already mention.

[NatPDeveloper]

LiquidAccounts are one alternative to traditional accounts. These are accounts stored in vRAM. This significantly reduces the cost of account creation, though it does require that contracts that interact with LiquidAccounts support them.

Otherwise you can just put the user’s account into vRAM when they begin their application session then remove it from RAM and store it trustlessly in vRAM after the user becomes inactive. There is a few second period in which it takes to load the user’s data which is why I propose loading and waiting until the user is done with their session before committing the data.

The amount of RAM that an app would need would be enough to cover all of their active users, they could buy/sell RAM as needed and if a futures market opened that could potentially further flatten the curve of uncertainty when it comes to costs.

[dragonheadbrother]

Amazing!
Agree with all of your issues!

Epecially the " Block Producers should be held accountable to standards", if the scorecard that EOS Nation built will be optimize for end users, and integrated into the coming EOS websit, it must be very useful for end users to know which BP is a good one.

And this must be useful to rebuild confidence for great BPs, who are hesitating to come back.

[benobi]

Let’s do as much as possible in this thread for now

[benobi]

Yeah, we should definitely write up some standards. Honestly, your team is probably best suited to do it.

Anchor or Wombat could be the main wallet, but I do believe that it should be super simple:

One chain only (EOS)
Shows balances of assets
Allows signing via EOSR
Allows transactions
Can purchase new account easily using In-App Purchase or import key

Later: shows NFTs, supports multiple accounts

[aaron]

I think what you’ve outlined matches our vision pretty clearly.

@benobi

One chain only (EOS)

The one difference I think would be here though.

I’m not sure if you’ve tried Anchor on mobile, but it attempts to avoid adding any confusion that multiple chains might cause. If you fire it up and create an EOS account, it’s going to be an EOS authenticator/wallet experience until you decide otherwise. That’s ultimately our vision for all platforms we build Anchor for, including desktop, which at this point needs to undergo some radical changes.

I’m pretty confident that once we hit the point where we’re actually happy with Anchor on all platforms, people will get it. It’s pretty far off from that vision right now but getting closer every day.

[aaron]

I need to learn more about LiquidAccounts and DAPP at some point. Both at a practical level as a technology and what sort of problems it could solve. Sadly I haven’t been able to find the time to really get into it and pick it apart. I’m excited to see things continue to happen on that end but I really can’t even hold an intelligent conversation about it

[benobi]

I use the TestFlight version daily - it does not show token balances in the app, but the authenticator works great.

[aaron]

It doesn’t show balances at this point, no. That doesn’t mean we don’t want that information easily accessible from within the app at some point in the future though.

My post was more agreeing that our two visions do align pretty well for what it should ultimately become (it’s not there yet), I just questioned the one point on whether it needs to be exclusive to a single chain.

[NatPDeveloper]

I just launched our new documentation as well: http://liquidapps.gitbook.io/. Feel free to reach out with any questions @natpd on Telegram

[benobi]

I believe that it needs to be as simple as possible. Anchor is an amazing tool. It doesn’t “need” to be single chain - but it needs a basic and advanced mode. I think it’s possible to use Anchor for this and I would be happy to wireframe for a simple interface and chat with you about it.

[maxo_Coin]

About your point about how you envision the account creation process
I agree, creating an account is cheap, comparing it with even one TX on Ethereum or Bitcoin

But there is a use case that is not covered, a DAPP creating accounts for their users
I would love to be able to transfer funds to an exchange without needing a MEMO field, or that any Dapp could have the easy onboarding that Upland has (most users transfer Fiat to play, that covers their costs, but this is not the case for many Dapps)

Ideally some kind of “Dapp account” should be created, that shares the creators RAM and CPU for whitelisted actions, or even are fully controlled by the creator’s account (account aliases)

This would allow DAPPs to create accounts for new users without the extra cost