About

What is Redgold?

Redgold is a peer to peer database and compute engine. It offers the functionality of a cryptocurrency, with schema level support for multiple independent currencies (ERC-20 equivalents,) as well as ETF & Portfolio support, native swaps & AMMs, WASM executors, and more. There is a special focus on exposing database functionality to application developers in the form of SQL for decentralized applications, along with data lake support. It uses a novel approach to consensus, and is designed to be a general purpose platform for decentralized data and compute with special support for financial use cases.

Conventional Motivating Problems

One of the largest criticisms of crypto as a whole is that it doesn't offer solutions that apply to other more conventional problems. Ignoring for a moment rebuttals about the benefits of decentralization, sound money, and the obvious real-world benefits and use cases, this is a valid criticism in the context of executors. Bitcoin scripting language, and the EVM by extension, do not really see serious adoption anywhere outside the smart contracting ecosystem, despite the fact that similar commercial problems exist for separate problem domains.

It is a well known problem that many large commercial enterprises face of dealing with secure remote code execution, typically desired by customers or users of a platform, who wish to enable some form of programmatic customization or integration with their own systems at a deeper level. This problem crops up in many companies, and is typically dealt with by deploying platform-specific cluster instances which duplicate entire environments for each customer, OR by having language subsets or massively restricted multi-tenant execution environments, for which you can supply small functions. Either of these approaches comes with problems. In the first case, you waste tons of resources & deal with the data enrichment problem of moving platform datasets close to the customer, which comes at a massive replication cost or authentication cost. In the second case, you have to deal with the problem of excessive limitations of a specific subset sandbox typically arbitrarily chosen within some commercial domain restricting the customer to conformance with that.

Neither of these approaches works very well, nevertheless they are strongly in use. It is our belief that the proper solution to this problem carries strong overlap with executor solutions central to the cryptocurrency ecosystem. While the consensus and conflict resolution problems associated with decentralized networks are substantially different in the commercial space (in the sense that they are either not required in many cases, or only required in exchanges or contract across conventional companies,) the data-store / data-lake / executor engine problem with untrusted is in many respects identical. It is our belief that the additional components associated with peer behavior, will also be important in the future for commercial applications, and that attempting to solve both of these problems will be a key component of the future of decentralized applications.

It also seems that any solution to this problem, should naturally draw upon existing solutions to similar problems, namely the use of SQL, data lakes, and WASM injectable UDFs and executors. While other projects have definitely made use of WASM executors, they are still attempting to do so within the context of isolated contracts with internal persistence layers, as opposed to a more conventional approach which a commercial application would take of treating the WASM layer as an injectable user specified function, and the persistence layer as a shared data lake with SQL access. This is a more conventional approach, and one which is likely to be more familiar to developers, and should make it far easier to build applications on top of the platform, as well as be re-used by other smart contract systems.

In order to achieve this, re-architecting the consensus & conflict layers is essential, which is why this project is mostly starting from scratch, re-using as many components as are reasonable, and basing the design around existing research papers on proposed consensus techniques from leading researchers.

What inspired this?

The first motivating problem is that of the social proof issue with conventional networks. Blockchains are meant to provide security in an open context, but that security primarily derives from the socially accepted active software fork and chain data hash. PoW and PoS blockchains frequently discard the chain data to switch software versions, make manual revisions, or otherwise determine what is the "correct" network.

This process is extremely arbitrary, error-prone, subject to manipulation and attacks, and otherwise manual. Local peer decisions based on scores (even if manually calculated) are the ultimate arbiter of security. This process can benefit from inference and automation.

Additionally, as the end goal per transaction is simply a merkle proof associated with acceptance from the prior mentioned peers, there is no need for a sophisticated chain data structure. It can be eliminated & optimized away entirely, and only the final stage produced directly, yielding a "local" or relative model of security & validation

The second motivating problem is oriented around scaling issues associated with smart contracts & support for database-like interactions. Blockchain is conventionally treated as an open world database, but operations are expressed as state transitions associated with a single contract. This would be the equivalent of serializing a class as a blob in a database, reloading it and executing functions against it for a conventional application -- something that ignores proper data store design considerations entirely.

The third motivating problem is issues associated with DeFi & bridge design. Most "trustless" bridges obfuscate a serious security issue across networks, which is the inability to re-validate the state associated with a given blockchain. This is a fundamental limitation with being unable to run an entire node within the contract of another platform or network, and is unlikely to soon change. That limit creates a situation where the subset of peers which provide state information to the given contract, are themselves providing the security.

This ends up degenerating down to a similar risk profile as a multi-signature custodial group. There are some variations, but it fundamentally shares a great degree of commonality. The problem of course with these types of models, is that there are numerous potential groupings of peers, as seen by wrapper coins backed by central companies, competing wrapper coins on the same platform, and different contract implementations. All of this is a byproduct of attempting to mitigate risk with different designs, but it hints at a potential design constraint.

The correct model to represent this is again, a local or relative one. As security is determined by peers, and each peer may have a different risk profile rating of other peers, the ideal wrapper is actually a custom weighted portfolio of different bridge providers. This property extends as well to more complicated cases, such as ETFs and portfolio target models / contracts.

What's with the name Redgold?

Redgold or "philosophical gold", is partially named as an ideological opposite of "BlackRock".
Additionally, as Ethereum was named after a mythological material from Castle in the Sky, Redgold is named as an indicator of the philosopher's stone a well known mythos relating to the construction of gold.