Last year, blockchain technology proved its mettle against the backdrop of a failing financial order and a thinly stretched health sector. The growing allure of this technology stems from its innovative approach to recurring issues in a broad range of industries. Recently, Jack Dorsey, the CEO of Twitter, his commitment towards utilizing blockchain technology to engineer a privacy-focused and fully decentralized social media platform. In the financial scene, we have the fusing of digital assets and legacy systems, which gave birth to the central bank digital currencies (CBDCs) and other blockchain-enabled banking operations. As such, there is no doubt that blockchain technology and cryptocurrencies are here to stay. reiterated witnessed Regardless of this simple truth, we are a long way from fully maximizing the innovative power of blockchain. Remember that the technology is just a decade old, and there are a few aspects that need improving. One of such is the recurring latency issue of established blockchain networks like Bitcoin and Ethereum. The latter, in particular, plays a pivotal role in the development and establishment of blockchain applications. Also, it is not as simple to use as an average user would expect. There is an unwanted level of complexity that comes with developing and using blockchain infrastructure and the associated applications. And so, it has become necessary to re-engineer the systems that power existing blockchains or adopt alternative networks with a more scalable architecture. Blockchain and cryptocurrency provide an abundance of possibilities if only we can unlock the current restrictions. Therefore, several development teams are working relentlessly to create functioning solutions to deliver an optimized blockchain experience. This is where Prasaga Foundation’s experienced developers enter the fray. Prasaga has designed the DataGrid Blockchain, with a proof-of-concept XBOM operating system on the robust HyperLedger Fabric network with arrays of features, designed to double down on already established blockchain functionalities and introduce improved iterations of redundant infrastructures. The goal is to develop a decentralized Layer 1 blockchain infrastructure, the DataGrid Blockchain, as an easy-to-use and scalable ecosystem where developers, miners, and token holders can co-exist. DataGrid Blockchain utilizes a next-generation architecture that finds a balance between enterprise and consumer-based applications. Another thing that makes DataGrid Blockchain unique is the economic design of its ecosystem. The native token has a shifting monetary policy that initially enables deflationary protocols and would later evolve to a stablized coin as the blockchain matures. Having explored all these functionalities, it was clear that DataGrid Blockchain and its accompanying XBOM OS come with massive technical ingenuity only ever witnessed in the very best of blockchain solutions. Hence, I reached out to Prasaga CTO David Beberman, for more information about the project. Below is an excerpt from our discussion. What is your take on the current state of the blockchain scene? Have stakeholders done enough in terms of functionality to establish the innovative power of blockchain technology? Edward Moon: We don’t have enough domain expertise to evaluate if other projects have done enough to be able to solve the difficult technological problems that most blockchain projects face. We can only speak for our own realization 2+ years ago that if we were going to be able to deploy our original Smart City/IoT data marketplace solutions we would need to build one that was fully decentralized, capable of scaling, secure against attach and still easy to develop for we’d need to build it ourselves What are the areas that need to be improved upon before blockchain can emerge as a mainstream technology? Edward Moon: The keys are ease of development, parallelization and scaling, while maintaining the security equivalent to PoW and building a stabilized currency for use in transactions. All, of course, within the context of truly decentralized blockchain operations and community governance. How have you gotten your sharding to solve a problem that others haven't? Why is XBOM well placed to handle the scaling needed and how is it different to other smart contract blockchains? Edward Moon: There are two parts to answering this question: transaction and data sharding, and consensus for sharding. For transaction and data sharding, the main difference is that instead of aggregating the user’s ownership of data (i.e., tokens and related) from all the users in a single smart contract and associated address space, we have separated each user’s ownership information into their own account. Using a smart contract approach, any inter-smart contract communication, for example a DeFi contract that uses 2 ERC20 smart contracts, requires data transfers between the smart contracts. If these are on different shards, then inter-shard communication is needed for every single transaction. Although this is possible, completing a smart contract now requires dependencies on smart contracts executed on other shards. Although it is possible to move all the smart contracts on to a single shard to execute, instead of doing cross-shard communication, such movement involves moving all of the data for all of the account ownership information in the smart contract to a new shard, even though the need to move it is because of a single transaction. Our approach is to change the concept of a smart contract to an object-oriented model. This enables each user’s account to contain objects and object references relevant to that account only. Because of this, we can implement rules that state the following: All accounts that are used in any given transaction must execute on a single shard. Only one transaction can be executed on a given user account across all shards at any given time (i.e., block). Because with the law of large numbers, it becomes highly probable that there are multiple transactions involving entirely separate accounts, the opportunity for parallel transactions on multiple shards are continuously possible. This enables a more optimal overall throughput, while reducing the inter-shard transfers, as the amount of data in a single account is much lower than the aggregate of data within each current smart contract. The second part of the answer is part of the consensus algorithm. As is well known, a single blockchain using Proof-of-Work (PoW) consensus does not increase throughput with added node resources. Instead, the PoW becomes harder. This does increase security but not throughput. Using Proof-of-Stake (PoS) consensus in place of PoW reduces the wasted energy on a per-node basis to accomplish similar throughput as PoW. Adding nodes to a PoS blockchain can similarly increase security, but the blockchain runs at whatever the design parameters are. What is needed is an ability to increase throughput with increased resources (i.e., nodes) without sacrificing security. For the DGB this is accomplished by enabling the dynamic creation of additional shards when there are sufficient new resources available. The means for maintaining security is due to the use of our PoS/PoW/distributed PoW consensus. Some of this is described below. I believe that the majority of developers understand what needs to be done. So, why is it proving difficult to eliminate the challenges associated with blockchain development? Edward Moon: Would slightly disagree solving the problems of security, scalability and decentralization simultaneously are not well understood, or at least unsolved challenges. There are tradeoffs to every solution implemented or proposed. For example, if the blocktime is increased for a Bitcoin-style blockchain, it will have higher throughput, thus scale, but at the expense of security. If the number of nodes/miners is reduced, it’s possible to increase scalability but decreases decentralization. Would also make the distinction between permission less blockchains and permissioned blockchains. In a permissioned blockchain it is assumed that all actors – clients and miners are trustworthy. This removes one aspect security, which enables more scalable consensus algorithms than the Bitcoin-style POW. However, they do so at the cost of decentralization – how do the clients and miners become trusted? In a permissionless blockchain the clients and miners must be completely trustless. It must be robust in the presence of intentional bad actors. What the DataGrid Blockchain architecture and consensus algorithm does is take a different approach to the trilemma tradeoffs, and substitutes network bandwidth for aspects of security, and sharding for scalability. Further, the current approach to smart contracts causes a serialization of unrelated transactions that could be executed in parallel in a sharded environment. To that end we rethought the smart contract approach and substituted a first-class object model and architected accounts as consisting of an object containment tree, with the XBOM operating system. What is Prasaga doing differently, and why do you think that Prasaga will succeed where many have failed? Edward Moon: There is a story that my Co-Founder our Chief Collaboration Officer, Jay Moore, enjoys telling. That I believe explains our biggest differentiation: “I believe the real sea-change is in Ease of Use. When I was at GarageGames, we’d available-sourced the 1st AAA game engine, The Torque Game Engine, we’d coined the term “Indie Games” and “Indie Developer” and built a community of 250,000 “Indie Devs”. I was at WWDC in 2005 and I saw Unity demonstrated for the first time. I called our CEO, Josh Williams, and had him fly from Eugene, Oregon to San Francisco that afternoon. I had him watch the demo and told him if we couldn’t make our engine as easy to use as how they were able to drag and drop art into the scene graph, we were done. Let’s just say that Unity has a market cap of $41Bn and GarageGames sold to Barry Diller’s IAC for a reported $70Mn. Ease of use will disrupt markets more than technology every time.” Who are the individuals that make up the team, what are their experience levels, and more importantly, why are you well placed to deliver such a forward-thinking solution? Edward Moon: The majority of the architecture and thinking behind the patents and technical Whitepapers are my own, but no one works in a vacuum and I have a 40+ year career in having solved these kinds of hard problems so I’d say that I’ve learned from many colleagues over the years. One sounding board beyond my co-founders, Michael Holdmann and Jay Moore, was Ossip Kaehr, Founder & CTO at Algorithmic Creations llc, who has had experience in architecting blockchains. I would be remiss to not say that all the other project White Papers helped me to sift through mostly the paths I didn’t need to go down because in building our designs, Solana, Hashgraph, Stellar, Bitcoin, Ethereum and many others all had an influence just to understand the current zeitgeist of where blockchain technology is now. Speaking of the technical prowess of your team, how have you implemented sharding to solve a problem that others are finding hard to resolve? Edward Moon: I will admit to being a bit old school. I don’t actually begin coding until the designs are complete from beginning to end and in this case, we wrote all the patents. Our current raise will allow us to recruit and task all the moving parts of our technology stack. Small teams many who I’ve worked with before will likely divide up into 6-8 specialty areas and we’ll be able to divide and conquer our way through to mainnet. I read that you are creating a Blockchain OS, XBOM, from scratch. Why do you believe that XBOM is well placed to handle the scaling needs of the DataGrid Blockchain, and how is it different from other smart contract systems? Edward Moon: The XBOM is not a smart contract system in the context of how smart contract systems work today. For example, a smart contract on Ethereum consists of all the code for the smart contract and a single state space in a single account. All transactions are sent to this account. Although the Ethereum EVM does support calling libraries of code that have been previously loaded on the blockchain, there isn’t a formalized way to separate code and state space. Further, there isn’t a way with smart contracts to separate the data on a per account basis, which forces unrelated transactions on a smart contract to be serialized. The XBOM formalizes the reuse of code loaded through object inheritance on the blockchain and enables state space to be managed on a per account basis naturally. The upshot of this is the state space separation enables parallel execution of transactions between unrelated accounts on separate shards. You claim that DataGrid will be language-agnostic so that developers can run the code seamlessly on the blockchain. According to the team, this will replace the need for Smart Contracts with Smart Assets. How does that make development easier? Edward Moon: Using a meta-class or first-class object model in a late dynamic binding environment, the class code for each class is stored on the blockchain similar to how smart contract code is stored on the blockchain. Because inheritance of methods between classes inheriting from each other is managed by the XBOM class manager infrastructure, the specifics of what programming language a specific class uses to implement its methods is transparent to any class it inherits from, any class that inherits from it, and the class manager infrastructure itself. This makes it possible for developers to implement their class code in a programming language they are comfortable with (provided an integration with the XBOM class manager infrastructure exists). Seeing that you have chosen to use a Distributed PoW/PoS approach, it must have a crucial impact on the operations of your offerings. What drew you to this consensus model, and why do you believe that PoW/PoS is more secure against attacks? Edward Moon: The DGB Distributed PoW/PoS combines both consensus approaches in a unique manner. One of the fundamentals of Bitcoin’s PoW approach is that the blockchain is immutable itself, independent of the miner source that created each block. Verifying the blockchain is valid does not require any information from any specific miner. However, the security of a PoW blockchain is dependent on the majority of miners being valid. When applied to a sharded blockchain, the PoW security is divided by the number of shards. This creates an opportunity to attack an individual shard easier. This limits the direct applicability of PoW to sharding. PoS security includes trusting that the private keys of the miners have not been compromised. Hackers that obtain enough private keys might perform some sort of masquerade attack, in particular a long-term fork attack causing transaction reversion and potential double spend attacks. However, PoS is much more energy efficient since there isn’t a need for all the miners to search for the hash solution. In a sharded blockchain the number of miners that needs to be compromised on an individual shard is also reduced thus reducing the security against hackers as well. One solution for the PoW sharding issue is to send the PoW results from each shard to other shards on a regular basis. This is sometimes called braiding. For the shared PoWs, the braiding incorporates all the hash power of all the miners on all the shards thus delivering equivalent security of having all the miners on as a single PoW consensus blockchain. The Distributed PoW approach of the DGB uses this approach to harness the total PoW security. On the intra-shard consensus component though, PoS in a PBFT consensus enables various other features of the DBG which enable the operation of the dynamic multi-sharding environment. To avoid the aforementioned long-term dependency on private keys by the miners (also called validators), a two-stage consensus is used, where the PoS is used for a block consensus and then a PoW is used to protect against a long-term attack. The PoW portion also enables both the braiding. The combination of the PoS and PoW also makes possible a verifiable random number function (VRF) that is at least as hard to spoof as forking the DGB itself. The VRF is then available for use within the overall DGB operation itself. Is token governance a viable way of establishing order on the blockchain, and how do you see this changing the nature of your monetary policy? Edward Moon: Deep token governance, or algorithmic governance enables management of the amount of coin in circulation which enables a distributed global reserve currency management. The well-known implementation of Bitcoin does not enable any managing the amount of currency in circulation in response to any economic factors. The result is volatility. Similarly, solutions that just continually increment the amount of coin through fixed amount minting also are not responsive and thus highly volatile. What is needed is a token governance policy that manages the rate of minting of new coins and the burning of existing coins incrementally to implement a policy intended to limit the volatility of the currency. By managing the currency in this manner, reducing volatility makes it possible to use the coin in wider commerce applications, where volatility risk currency is unusable. Is there a reason for enabling your monetary policy with the capacity of changing your token from deflationary to inflationary? Edward Moon: As in the previous question, a deflationary currency causes the currency itself to be the entity of value instead of the “buying power” of the currency. This is because by being deflationary by definition the currency itself is a scarce resource. A currency that inflates with the amount of increasing economic activity causes the entity of value to be the assets being transferred for currency (i.e., how currencies are intended to work in most economies). In order to balance the concepts of increasing the value of the coins themselves with the intent to make the coins useful as general currency, the DGB monetary policy starts out managing the number of coins in circulation with the intent that the economic activity outstrips the coins in circulation. This creates the deflationary effect. Over time, the algorithm will manage the coins in circulation to reflect the increase (or decrease) in economic activity. This makes it an inflationary currency as it will inflate with increased economic activity, conversely it will deflate with decreased economic activity, creating a stable internal value on the DGB. Note that this does not imply the value of the DGT coin is marked to any external basket of assets. I discovered that , the Estonian private limited company that is facilitating regulatory compliant token offering is about to finish its Private Presale and Community token sale, February 13th, Following the completion of these stages, the next step is the launch of DeFi pools. If I may ask, why have you chosen to use the Balancer Liquidity Bootstrap Pool (LBP)? Edward Moon: DGB Labs OÜ The Liquidity Bootstrap pool simply allows the full market, not bots or whales to set the value of the DGT Token - $DGT. The pool is funded on both sides, one with USDC and the other with DGT. The beginning and ending weights of each asset is set, $DGT a higher early percent of the pool. Each hour for 96-hours, weight adjustments are applied to the $DGT causing the spot price to go down, this stops the whales from coming in early and dumping on everyone). The market now decides what the value of the $DGT is by starting to add USDC to the pool at the chosen price causing the $DGT to stabilize or increase in value depending on the amount the market is adding. The first example of this is PERP, which had a 72 hour approach they documented in . Medium When should we expect DataGrid Blockchain and its operating system to go live? Edward Moon: We have already verified the XBOM architecture, design and prototype on Hyperledger Fabric, and can be run on a local testnet. We expect to reach a DGB mainnet and a first release of XBOM in approximately 12-18 months from pre-sale close.
