Community Update — July 20, 2018
An introductory glance at “dApps for Everyone.”
Our goal is to simplify smart contracts, the process of sending/receiving cryptographically-assured payments, and deliver tools that are functional, valuable and easy to use — no matter your skill level.
Sometimes this means prioritizing a beautiful user experience to make sending payments easy, and other times it means solving really complicated problems on the back-end to make things seem easy.
But building user-friendly dApps that appeal to more than just the crypto audience is easier said than done.
There are inherent challenges and limitations when building on any blockchain, and unless you’re digging around in GitHub or actively involved in a development project, you’re probably not even likely to hear about them.
One thing you probably have read a lot about is scalability. This has been a hot topic in the Ethereum community lately, and ideas like sharding and off-chain transactions are promising fundamental fixes. But how does scalability impact blockchain development today?
How this impacts development.
A large chunk of any blockchain development team’s time is dedicated to simply figuring out what’s possible. Once there is a clear understanding, the next step is trying to figure out how to get around or otherwise balance the tradeoffs associated with decentralization, trustlessness and usability.
Take scalability for example — how does that affect our development?
In our upcoming product, Tabby Rewards, users will be able to input their selected ERC20 token and generate a list of redeemable codes that they can distribute in any way they please. This is useful for token creators, to distribute tokens in exchange for marketing efforts or within the context of a game, contest or application.
For some technical context, there is a current hard cap on gas at approximately 8,000,000 per block. To many, this may be a surprisingly limitation: it represents a limit of approximately 7 kilobytes of storage per 30 second block — for context, dial up internet was capable of transmitting more than that per second.
When it comes time to generate the codes for Tabby Rewards, we have essential blockchain-level engineering tradeoffs to consider — a triad of challenges: users must manually sign each transaction (along with a single-use code called a nonce), directly on-chain data storage is severely constrained, and decentralization and trustlessness is a core philosophy of the platform.
The initial “obvious” solution — storing the codes directly — is completely prevented by the block gas limitation: if that were the mechanism we were to use, it would represent a constraint of generating less than 100 codes, with a very expensive gas cost to boot; instead, we approach it with a novel cryptographic generating mechanism, allowing an unlimited number of codes to be generated.
These, and many other, experience and engineering constraints are often surprising to non-blockchain developers: they require a totally overhauled, more cryptographic form of thought.
All these technical constraints materially impact the development effort — when we’re talking about new cryptographic models, we need significant validation and testing to ensure security; when we’re talking about user experience, we need to ensure the use of a blockchain improves the platform rather than limiting it only to the most sophisticated users.
What this boils down to.
It boils down to this: building safe, user-friendly, decentralized blockchain applications takes an incredible amount of time, dedication and effort.
There are a seemingly infinite number of variables to consider, especially when you’re dealing with what is essentially high-risk financial applications. While these challenges aren’t uncommon for any area of development, the stakes are much higher when there is immutability and real monetary value involved.
And the reality is — most of these challenges aren’t glamorous. They can’t be solved with “marketing”. They’re difficult to conceptualize and write about, because they’re often far too technical for the non-development crowd.
From an outsider’s perspective, it might seem like a team is moving slowly for no apparent reason. We’ve all watched milestone dates get pushed back, or a platform release that falls short on expectations.
But the reality is that if the team is (actually) building something, they’re probably trying to figure out ways to overcome challenges like scaling, gas limitations, private key storage, network congestion and more.
Any team who is legitimately developing on the blockchain is contributing to the shared future we all believe in. These problems are all worth solving — but sometimes they can take a little longer to do so properly, simply because there are so many core pieces missing.
Taking a bit more time to build proper tools and infrastructure up front will allow the community to build even more incredible things down the road.
Dev Notes
A few quick notes about what went on behind the scenes this week.
🐞 Bug Fixes:
+ currency selector styling fixes for smaller screen widths
+ standardize and improve transaction blobs rendering
+ clean up redux polling infrastructure💻 Feature Development:
+ gas forwarding is complete and is now being tested
+ new send tokens pre-auth flow improvements👉 Internal:
+ new infrastructure design for smart contract generating functions
That’s it for this week! If you have any questions, be sure to join our Discord channel, tweet to us on Twitter or chime in on the /r/BlockCAT subreddit!
