DAPP Solutions Great Reddit Scaling Bake-Off Proposal
Github : https://github.com/DAPP-Solutions/redditEthDappSol
LiquidApps/DAPP Documentation: https://docs.liquidapps.io/en/v2.0
EOSIO Documentation: https://github.com/EOSIO/eos
DappSolutions Telegram: https://t.me/DAPPSolutionsCommunity
About DAPP Solutions:
DAPP Solutions is a full cycle development ecosystem and DAPP Service Provider (DSP) on the Liquidapps DAPP Network, a universal middleware of powerful services for modern decentralized applications.
https://dappsolutions.app/
Our Team:
Jason Kemp, CEO
John Campbell, CTO
Ami Heines, CIO
Arunima Ray, Developer
Prasanjit Dey, Developer
Submission Tools:
Ethereum (ERC-20 Token model) https://github.com/ethereum
EOSIO (Network Resources) https://github.com/EOSIO/eos
LiquidLink (IBC) https://liquidapps.io/liquid-link
LiquidOracle (Web-interaction/IBC) https://liquidapps.io/liquid-oracles
LiquidScheduler (CRON) https://liquidapps.io/liquid-scheduler
vRAM (Memory) https://liquidapps.io/vRam
The Goal
Short Term Goal:
Reddit/Ethereum Scalability and Resource Efficiency via Blockchain Interoperability
Team DAPP Solutions would like to start by saluting Team Reddit for leading the charge in mass adoption of blockchain technologies. We will show our appreciation by developing a Reddit Community Points solution that is verifiably inexpensive, scalable and secure.
Long Term Goal:
Blockchain Agnosticism | One Network
It is a sincere pleasure for us at Team DAPP Solutions to be engaging directly with the Reddit and Ethereum communities. Those of us familiar and engaged with the LiquidApps DAPP Network have waited patiently to showcase our unique and differentiated services towards a positive sum gain for all.
Interoperability | InterBlockchain Communication (IBC)
On July 26, 2019, CryptoTwitter was treated to a demonstration by the LiquidApps Team of blockchain interoperability using a DAPP Network service called LiquidLink.
Link here:
https://twitter.com/LiquidAppsIO/status/1154842918705926145?s=20
Our slogan at DAPP Solutions since our inception is "Onboard Everyone", so we were very excited last July to watch blockchain interoperability come to fruition between the Ethereum and EOSIO-based blockchains.
The DAPP Solutions Team is excited to be able to introduce Reddit and the greater Ethereum community to the LiquidLink bridge between Ethereum and EOSIO. This DAPP Network service leverages the benefits and communities of both technologies in moving towards the greater goal of interoperable, scaleable and decentralized blockchain solutions.
Submission Timeline Explained:
As you review our proposal, please understand that we entered this challenge on July 11, following the LiquidApps July, 6 code upgrade to LiquidLink, and accompanying Medium article,(https://medium.com/the-liquidapps-blog/the-dapp-networks-reddit-scaling-bounty-d60e057de6d) specifically upgraded to take on the challenge of the Great Reddit Scaling Bake-Off.
The article echos our sentiments at DAPP Solutions:
"Despite getting the ball rolling on Ethereum scalability, Reddit isn't the only one that can benefit from the DAPP Network's unique cross-chain middleware. Any Ethereum project that wishes to scale without leaving its native ecosystem, could utilize such a mechanism to go where no dApp has gone before — mass usage."
With limited time and resources available to us, we chose to focus on interoperability, scalability and resource efficiency with the intention of integrating with one or more existing wallets by the time submissions are reviewed and chosen.
Now with an upgraded version of LiquidLink, we set out to show our blockchain brethren what our tools can do. Our solution relies on the EOSIO infrastructure, as well as a L2 solution called the DAPP network to scale the EOSIO network's capabilities and resource management.
Our goal in providing this POC is to demonstrate how the DAPP Network can act as a live, advanced middleware to scale the Reddit Ethereum model while ensuring resource and cost efficiency.
Demos Should Include:
- A live proof of concept showing hundreds of thousands of transactions. (Pending)
- Source Code (See GitHub link above)
- Documentation:
- How it Works and Scales:
- Ethereum for distributing/minting tokens in ERC-20 format when users want to remove them to popular Ethereum wallets, as well as token burning when users send funds back to the account for re-entry into the EOSIO/DAPP side of the system.
- EOSIO storage/computation to manage user balances, community distributions, purchased community features and other community functions that feed into the user balance system upon a successful round of user distribution (via karma/voting as the system is currently implemented on reddit).
- The DAPP network for its ability to call Ethereum networks through a service called LiquidLink, which allows us to make calls to ethereum at regular intervals to update the latest IPFS hash tip. This lets us store the latest version of the memory implementation so that any DSP running the LiquidApps contract logic will be able to rebuild and continue to run the system.
- The DAPP network for vRAM which uses IPFS to scale the storage potential of an EOSIO contract, making the upper-limit and resource usage of the contract as minimal as possible. This storage object has a hash for the latest entry which can be used when storing on ethereum.
- The DAPP network LiquidOracle for Oracle services, in order to determine if user balances have been submitted back into the system (burned on the Ethereum contract and re-assigned to the user in EOSIO storage).
- The DAPP network for LiquidScheduler, a cron-job library for calling ethereum at regular intervals to update the IPFS hash and to execute anything needed on the ethereum network.
- Cost Estimates (on-chain and off-chain):
Comparable metrics will be posted to the demo page, which will be linked from the github. (pending)
EOSIO requires that system tokens be assigned to the contract (EOS on the EOS mainnet) for CPU, RAM, and NET. Both CPU and NET usage limits are returned to the account (linear timeline to return of resources), which is similar to the DAPP token in that once these tokens are staked, you can increase your stake in a given resource when needed, however they can be returned/un-staked and sold - so while there is an initial setup cost, the ongoing costs will be greatly reduced, and largely predictable.
Anyone can add resources to the contract when usage increases, these resources can all be unstaked/sold if usage decreases, or if a new contract is introduced to manage the system etc. RAM on EOSIO is bought and sold on an internal market, and does have an upper-limit.
However, the vRAM solution through the DAPP network will allow us to remove this upper-limit, and convert it into a quota of X number of calls for Y number of DAPP tokens, which can be modified accordingly without requiring more (or in some cases, a minor amount of) EOSIO RAM resources.
- How to Run It
Using our reddit simulator, and our demo page (pending), a web UI will be used to trigger the simulation while tweaking variables for efficiency.
- Architecture
- An Ethereum smart contract (existing SubReddit token contract) to be called for minting, distributing, and burning tokens per community, as well as storing the latest IPFS hash from the DSP.
- An EOSIO/DAPP smart contract which manages the community points system. This contract is interpreted first by a DSP (with consensus across multiple DSPs if needed for consensus checks to decentralize trust in a single DSP), then passed along to EOSIO for on-chain processing.
- User balances and subscriptions/purchases/sending of tokens between users.
- Community descriptions e.g. symbol, ETH contract address, and any other info needed (such as URLs for icons and other cosmetic community variables)
- Management of community distributions to users upon a submitted list.
- Calling the ethereum contract to mint/issue tokens to users that want to exit the system to an existing wallet.
- Calling the ethereum contract to update the latest IPFS hash for recreating the data (in case of any issue at the DSP level, the data inside the contract can be re-created from this hash).
- A node.js/postgres reddit simulation engine to generate user accounts with ethereum addresses, issue them karma, then distribute tokens according to karma rankings (recipient list approval not included). It is currently acting as our user ethereum wallets for testing purposes, and otherwise seeks only to replicate and randomize reddit usage in relation to the community point system.
- API's (on chain & off) : Ver 1.0 N/A We have built a Reddit Community Point Simulation
- End-User Case
Dependent on wallet collaboration/integration for API to connect to reddit.
- Known Issues:
Pending:
- A demo including an end-user interface for signing transactions with their ethereum-based wallet.
- Code attached to submission for how to use same private key for both EOSIO and Ethereum accounts, easily implementable for any existing ethereum wallet to support calling both EOSIO and Ethereum-based chains using a shared private key across networks.
- To link ethereum point burning back to user balances in the system.
- Also a plan for integration using the DAPP network's LiquidOracles implementation to check what tokens have been burned, and from what address, so that the EOSIO/DAPP model can update the user account's balances to reflect changes in subscriptions and purchase of community features.
- Comparative metric outputs (and easily able to be run in a random manner in regards to user accounts and community interactions to ensure consistency, which is already in the simulation code).
- Functional demo page to be completed - linked on github.
Requirements
Scaling:
Our PoC (redditdapp.cpp) and test contract (main.cpp) currently tests and has consumed all necessary services to meet the requirements:
- 100,000 point claims (minting & distributing points)
- 25,000 subscriptions
- 75,000 one-off points burning
- 100,000 transfers
We are in the process of setting up our live demo page to show the system in action, which we will put onto the github repo in the coming days, so be sure to check back!
Decentralization
DSPs are chosen by the EOSIO/DAPP contract owner (which would be reddit in this submission's case), however many DSPs can be selected by that contract and utilized to create consensus amongst calls, as well as to decentralize the trust desired/required when working with them across many parties.Through a combination of these services, we can decentralize every part of the system.
Useability:
While we still require a wallet to integrate with our solution, our Reddit Simulation Server is mimicking wallets for the sake of demonstration. Outside of this implementation, the system self-manages assuming there are enough resources (both for gas fees on ETH and for account/network resources on EOSIO/DAPP).
Interoperability:
Using LiquidLink and LiquidOracles, we can both sign transactions on, and listen to the Ethereum blockchain as shown in linked examples/articles above.
Security:
All systems require private keys to interact with the contracts, and otherwise will only run on a scheduler. So long as private keys are only held for account resource management
Resource Efficiency
Through the usage of vRAM and EOSIO accounts, there are no TX fees outside of moving tokens onto/off of the Ethereum network.
The vRAM/LiquidLink/Oracles/Scheduler model requires that DAPP tokens be staked to a DAPP Service Provider (DSP), which must increase according to usage, but can be un-staked at any time.
Strengths of this approach
Cost/Resource Efficiency
Without the need for transaction fees at every interaction in the system on the
Ethereum network, we should be able to bring a majority of system costs to a minimum. None of the fees inside of the EOSIO/DAPP system are "spent" in the sense of transaction fees, and are refundable in the form of EOSIO system and DAPP tokens. These networks provide a much higher throughput at a much lower cost. The only time gas fees would need to be spent would be the update interval for the IPFS hash (sped up for simulation purposes, but this interval can be set to any amount of time), then token minting/issuing/burning gas fees should a user decide to exit or enter the system using an ERC-20 wallet. This implementation is also easily port-able to EOSIO tokens, which would speed up the system and remove transaction fees from the system entirely.
Flow of operations:
Community Perspective
- Community (reddit systems, not users) registers a subreddit with system (EOSIO) and loads the ERC-20 token contract onto an ethereum address for that community point/token (ETH) and to mint an initial supply for the ETH contract.
- Reddit submits token distribution per-month/round and includes user info, as well as community/token amount to the EOSIO contract (EOSIO), which then uses vRAM (DAPP) to query and store the information.
- LiquidScheduler runs on interval to check what events are queued to go out to Ethereum upon being triggered (DAPP)
- If any users have asked to exit the system (EOSIO), the queue is run through the LiquidLink service (DAPP) to send a signature to ethereum to send tokens to their ETH accounts (ETH receive).
- To re-enter the system, users can send funds back to the community contract to be burned (ETH).
- During the LiquidScheduler interval check, it will call the LiquidOracle service (DAPP) to check for sends/token burns.
- If any burns are found, it will match the ETH address to the user account and add the funds back into their account (EOSIO/DAPP).
User Perspective (Dependent on cross-chain key signing wallet support)
- User receives community points from distribution rounds. (Reddit -> EOSIO)
- User can choose to subscribe to a community, or buy community features with tokens or fiat.
- If fiat, ETH contract will be called using LiquidLink to burn tokens (DAPP -> ETH)
- If purchasing with tokens, vRAM records will be updated to deduct from the user's balance without adding them elsewhere. (DAPP)
- These actions would be signed using an integration of the keycode.js file (included in github "wallet" folder)
- Can send tokens from one user to another, using a wallet implementation of keycode.js to verify before moving balances (EOSIO and potentially ETH depending on final wallet solution).
- Can select a set of community points to exit the system into their wallet (Wallet -> DAPP -> ETH)
- Can send tokens to the community's ETH address to re-enter the system, no burn needed from ETH in this case, so long as the initial token supply is minted on Ethereum (ETH)
- LiquidOracle Service will read ethereum network to check for received tokens to update vRAM for user balance. (DAPP)
https://preview.redd.it/wzs7firyybe51.png?width=1626&format=png&auto=webp&s=cfe8200c7450cb5385b2bc1638dd750cf2cb3a58
https://preview.redd.it/tlweyqi0zbe51.png?width=1626&format=png&auto=webp&s=846081b6356204d7231ad641960ad2c66ca1c3d3
https://preview.redd.it/6pbu4po1zbe51.png?width=1626&format=png&auto=webp&s=e07b59290812a5ad630e50693910d0f5d6090ecc
https://preview.redd.it/q41riha3zbe51.png?width=1626&format=png&auto=webp&s=f2f0803a7a6a602bff314ba932223d8e482d6caf
The DAPP Solutions Team welcomes your feedback, technical questions and fair criticism.
We'll be available via this thread or on our telegram at https://t.me/DAPPSolutionsCommunity
We humbly thank you for this opportunity.
Onward and Upward!
No comments:
Post a Comment