Issue #6: December 2019
Hello everyone!
This has been a big month for Greymass, as we’ve released our first major new product— Greymass Fuel .
EOSIO 1.8 introduced a new feature that allows third parties to pay resource costs for users on EOS. This is a huge step forward for usability, as most end-users won’t want to (and shouldn’t have to) manage the complexities of things like CPU, NET, and RAM. While this feature has been enabled at the protocol level, it still requires dApps, wallets, and other parties to do some tinkering in order to set it up. Greymass Fuel was created to directly address this issue.
Fuel is a two part project:
Part 1 is a public good/service that offers limited free transactions to any user, based on donations (aka delegations).
Part 2 is a premium service that offers dApps a plug-and-play solution to cover transaction costs for their users, with very little development effort required.
For part 1, we’ve set up a greymassfuel account that is configured to offer a limited number of free transactions to any user, based on milliseconds of CPU time. It is rate limited per account (currently set at 5ms of CPU time per account, per day). Use of this feature requires a specific type of transaction to be initiated by the wallet or application that you’re using, so it’s not instantly available to every account. Anyone is free to delegate their EOS resources to the greymassfuel account— it’s entirely non-custodial, and you’ll still maintain full control of your funds. You can see Fuel in action already at EOS Authority’s web wallet and EOS Nation’s proxy page.
For part 2, we’ve built a custom service that allows dApps and other service providers to take advantage of this new EOSIO feature in as easy a way as possible. DApps that cater to end-users should seek to abstract away the complexities of blockchain resource management. The new features introduced in EOSIO 1.8 allow for this, but individual dApps would still be required to have individual infrastructure, knowledge of how signing works, a backend service, and more. Rather than require each dApp to build that on their own, we created a turnkey service that offers dApps a plug-and-play option. We expect this to be cheaper and easier for dApp developers than creating such a solution on their own.
We’re really excited about the possibilities offered by Fuel (one of which Aaron outlines in the Twitter thread below). We think that it will help radically improve both user and developer experience on EOS.
Aaron Cox @Jesta187
I’ve been really excited to get this out into the public with how well it works using the EEP-7 signing protocol. For example, a proxy vote for our proxy: eosio.to/gWNgZACDVwahBa…Which is then signed using Anchor/Ledger, and billed to “greymassfuel”:bloks.io/transaction/2c…
Greymass@greymass
Over the past few weeks we have been working hard to explore the new #EOSIO feature that allows a 3rd party to pay resource costs for other users. Today we are ready to show off the prototype service of what we’ve been working on. We are calling it: “Greymass | Fuel”
November 12th 2019
1 Retweet13 Likes
If you are a dApp or service provider in the EOSIO ecosystem and want to learn more about integrating Greymass Fuel, please reach out to us at team@greymass.com. We’d love to help you! If you’re a community member who wants to learn more about Fuel or just get involved, feel free to hop in and join the conversation in our Fuel Telegram channel.
Now, onto the ecosystem news!
EOSIO Ecosystem Updates
B1 to Begin Voting
Block.one announced this month that they are planning to begin voting on the EOS mainnet. Their B1 account currently has ~89M EOS staked, making them one of the largest players in the game. That, combined with the fact that B1 holds an extremely influential position in the ecosystem, makes this a big deal for the future of EOS governance. No exact timeline was given for when or how they’ll go about the voting process.
This raises many questions— what kind of BPs will Block.one prioritize? Will they push back against existing vote-buying schemes? Will they vote directly or proxy their vote? These are all important questions that will likely be key factors in shaping the mainnet ecosystem throughout 2020.
Block.one Announces Voice Beta Release Date
Ever since Block.one’s June 1st event in DC, they have been relatively quiet on details regarding Voice, the blockchain-based social network that is set to be their flagship product. Now, they’ve finally broken their silence and announced a February 14th release date for the Voice beta.
One nugget of information that many missed, tucked into the FAQ:
While Voice is in beta and a highly iterative state, it will be run on a purpose-made EOSIO blockchain. In time, we would like Voice to leverage the EOS Public Blockchain, and potentially others that can meet the performance and governance demands of Voice.
This seems to be a backtrack on what they announced in June— that Voice would be built on top of the mainnet. As with all things B1, we just have to adopt a wait-and-see policy until we get more info.
You can also now follow Voice on Twitter, Facebook, and Instagram.
Proposed REX Changes
Both EOS Argentina and Bancor/Liquid EOS weighed in on the current inefficiencies with the REX market, proposing new changes that could address some of the existing issues.
You can read EOS Argentina’s proposal here, and Bancor’s solution can be found here.
Two things have become quite clear in recent months— the current situation around CPU is largely unsustainable, and REX has some flaws. We believe that addressing REX inefficiencies would be a good first step, before later taking a look at the entire resource ecosystem and trying to find ways to improve it (this is something we’ve thought at a lot about at Greymass!).
New Resource Allocation Proposal — Dan Larimer
On that note, Dan Larimer shared some thoughts on proposed changes to the resource allocation model employed on the EOS mainnet.
Dan confirmed on Twitter that B1 is working on coding up the proposal.
Daniel Larimer @bytemaster7Greymass Updates
New Article from Jesta
Aaron Cox (aka Jesta) from our team weighed in on some design considerations for covering transaction costs on behalf of users. Aaron has spent quite a bit of time diving into this subject in all the work he’s done on Greymass Fuel, so we highly recommend checking it out!
Full History is Back in Action
As some of you may know, we’ve had some issues with our history APIs in recent weeks. You can read the series of tweets below for a much deeper technical dive into the reasons behind the outage.
Greymass @greymassWe’re very happy to report that as of recently, our APIs are now serving full history again ! We’ve learned a lot in this process, and we’ve also gained confidence in our ability to take full snapshots of history data. We’re cautiously optimistic that our full history will remain online for the foreseeable future.
More Fuel/Anchor Updates Coming Soon
Greymass Fuel has been our major area of focus this month, but we’re also hard at work finishing out Anchor, our rebranded desktop wallet. We’re really excited to show the community how all of these various pieces— Anchor, Greymass Fuel, our signing protocol, our API work, and more— all fit together into a coherent vision for improved user experience on EOS and other blockchains.
For best way to stay updated on these things as they happen is by following us on Twitter and joining our Telegram group. We look forward to publishing more fun stuff soon!