Motivating Problems

Custodial Risk, Governance, Bridges, ETFs & Portfolio Target Models

One of the largest problems plaguing crypto as a whole is custodial security. An immediate example is seen in the collapse of LUNA, where billions in Bitcoin reserves were held internally by the company to 'back' a 'decentralized' protocol. Not exactly a 'zero-trust' system if we rely on a relatively small group of people to either hold reserves, or manage the funding of development of a project. There have been so many crypto startups, where the actual raised money is held by a small number of people, even one, which result in rug-pulls or other outright fraud or criminal behavior. Within these systems, the actors themselves usually constitute most of the 'stake' or collateral in the system, and thus demonstrate the most obvious attack against the network for PoS systems, which is of course the people who started it being extremely untrustworthy and using funds illicitly. Such operations are typically prevented in corporations by legal enforcement, and while some of that does extend to crypto development companies or otherwise, a corporation is not necessarily the best analogy for a crypto-system as a whole. The desirable property of interest in decentralized networks is secure notarization, auditing, and validation -- not necessarily to replicate the structure of a modern corporation (rebranded as 'decentralized'.)

For much the same reason, governance protocols are extremely suspect and subject to attacks. Whether considering the example of attacks using flash loans to manipulate DAOs into passing votes that drain funds from the network, or votes held at inconvenient hours (Solend collateral issue where 0.5% of the validators hijacked the collateral to prevent liquidation,) or simply networks which centralize the holdings (through exclusive pre-mines or massive dividends diluting other shareholders) and thus determine the outcome based explicitly upon the decisions of a small number of people subject to the same flaws as other centralized actors, -- governance protocols end up with a relatively similar problem as custody. In general, the problem of stake & ownership tends to treat the protocol like a conventional company, which has many limitations as the main goal of the network is really to act as a publicly available auditing layer & intermediary service. As an example, we have many independently competitive oil companies which collude together in cartels to fix prices and destroy environmental legislation. Certainly if we were to discuss what is the best way to audit them, the literal last solution we would ever come up with is to put themselves in charge of their own auditing and validation based on shareholder ownership stakes. This would result in instant collusion and foul behavior. The root of the solution here again, is based upon localized & relative decisions aggregating up to a global state, rather than an imposed global state. This will be discussed further later.

The next category of problems related to custody is of course bridges. Some of the largest bridges for Bitcoin are centralized custodian based bridges. Again this makes sense due to the difficulty of bridging BTC to ETH, as the contract languages and isolation of each network makes it difficult to reason about the state of either system from within one, but it shouldn't require a centralized 3rd party company to deal with issuance and redemption. Again also here, you have the issue of multiple potential centralized offerings, as there are many companies that offer this service competing for usage. The ideal 'wrapper' instead would represent a portfolio of different custodially held contracts, ideally each consisting of a multi-party agreement (multi-sig wallet backing.) Each user of these wrappers may have their own independent view of what is the best way to distribute these, which leads us to a unique 'relative' portfolio model for each potential user of a wrapper coin, with independent valuations based on the estimated custodial risk (relative to who is judging or assessing that risk.)

Zero-trust bridges, while sounding fantastic, are rarely actually implemented in such a way as to fulfill that promise. There are serious underlying security problems outlined by Vitalik even assuming the correct design. More fundamentally, for a 'perfect' bridge to operate, it must know exactly the state of both networks perfectly (essentially running a full node), and be able to embed an understanding of that state into a specified contract. This is essentially impossible for all major networks, as you cannot run an entire node within the context of a smart contract, and any data introduced within the chain context of one network is specific to that network -- external data is only available through oracles. Any attempted bridge, must at a minimum, run an entire full node of the network attempting to be bridged, any variation less than that introduces yet another weakness. Because of these constraints, most 'lock and mint' bridges operate in a realm where there is a small subset of nodes responsible for relaying this information, and it is trust over that subset alone which is backing the security. While again you can introduce collateral associated with those validators, the funds at stake can potentially be greater than the collateral amounts, as they can actually be stolen. All of these issues mean that 'lock and mint' style solutions are not substantially different from a multi-sig custodial model in terms of risk profiles, and actually potentially even worse due to the numerous exploitable errors found in these types of contracts.

The greater danger as well is that of synthetics in general in finance. Anyone who has been following the issues associated with GME and other 'short squeeze' style stocks has seen the potential for abuse by centralized financial services companies. Synthetic assets have created numerous historical risks in financial systems, especially considering even the 2008 crisis. While in theory a properly designed 'lock and mint' bridge would not be able to introduce duplicate coins (as opposed to purely synthetic assets like failed algorithmic stablecoins, and is hence at least a step above that,) in practice it has happened many times as an attack. Synthetics as a whole are dangerous, both individually and systemically. But, their reliance on at least some chain state data does differentiate them as useful compared to custodial models, and so should not be completely ruled out as a member of a portfolio of diversified bridge asset types.

Portfolio management is the proper way to think about bridge assets. Most coin ecosystems are filled with dozens of popular wrapper coins, and yet contracts are generally restricted to accepting a single one, confusing most users entirely. The proper separation here would be to think of the usage of a wrapped coin instead as being a weighted portfolio of raw wrapper coins, with the weightings determined by analyst rating based on the risk associated with each wrapper, relative either to the custodial, contract, or validator risk, as well as optionally the per-user rankings associated with wrapper popularity and rankings. This process ends up happening anyways for large scale holdings dealing with numerous wrapper coins, where they balance their risk by holding USDC, USDT, gUSD, etc. Instead this process should be automated so the average user can gain the benefits of diversification using standard analyst risk ratings (should they have no better knowledge themselves.) As seen by the restatement of this problem, this fits naturally into the model described earlier with peer trust scores. Given that custodial / contract / validator security risk on bridges provides a much greater incentive for dishonesty, it should act as a stronger proof of transaction security than even conventional double-spend security.

Furthermore, a desirable set of products for crypto users which is missing from the marketplace or under-implemented are crypto ETFs. Passive investment funds such as the S&P500 (SPY or VOO ETF) or other common currency based ETFs dominate the market by offering reduced risk and stability. Individual crypto assets can fail, and managing ownership of hundreds of different types of currencies with varying integration requirements, key requirements, API changes, and fees for re-balancing, poses a nightmarish hassle acting as a massive barrier to entry to all but the most sophisticated and wealthy users. Common users should be able to purchase and manage interest in the crypto market without being locked out, and to do so without incurring the risk associated with selecting individual coins. While there are some ERC-20 or Ethereum contract based ETFs built on wrapper contracts, they suffer from the same drawbacks and limitations mentioned earlier.

It may be suggested why not rely on some company which creates a centralized entity or ETF which acts like a holding company for these coins? Relying on the equivalent of Vanguard or any other ETF provider (and there are those attempting to follow this pattern.) There are substantial drawbacks to this in terms of security, transparency, and missing out on the power and purpose of decentralized networks. Traditional ETFs are generally not easily redeemable for the underlying notes of ownership for small shareholders -- nor do they provide open records on transactions and exact flows in and out of the fund in a secure manner. An owner of VOO or SPY for instance can not easily convert their underlying ownership to a fractional ownership of the composing securities unless they are a major investor or financial institution. While this may not pose a practical problem for most investors, it creates a systemic barrier to trustworthiness of the underlying products. In the financial industry, the core components for these products require complex and trusted valuation strategies and trusted escrows, the equivalents can be built in an automated fashion in a decentralized way to compete with traditional offerings.

A desirable property of a crypto-based ETF, which can potentially exceed properties of conventional ETFs is per-security redemption (with some restrictions to avoid underlying transaction fee penalties.) Additionally, redemption should be offered in major assets of choice, like allowing a redemption directly in some combination of BTC / ETH as opposed to in all securities (combining swap-like functionality). That would lower the transaction cost drastically while still proving liquidity. Furthermore, trackable and redeemable notes avoid the re-hypothecation problem entirely which typically plagues trustworthiness of centralized ETFs. There is a substantial and real concern about existing centralized crypto ETFs and whether or not they actually own all of the assets that they claim to. This is something that should not be in question, when the underlying assets themselves and transparently available to be inspected. While they do offer the benefit of bridging to conventional financial networks in the case of single-crypto ETFs like the proposed Bitcoin ETFs, more complicated multi-asset ETFs should be implemented in a decentralized way, and then bridged to a conventional ETF.

The core building blocks of such a group of products relies primarily on the integration of existing chain data from multiple networks, along with oracles of price information and the support of note redemption through decentralized custodianship & locking contracts. These building blocks, along with appropriate strategies for portfolio optimization & re-balancing, mechanisms for determining premiums, and deposit insurance, form a platform which can be used to launch many such ETFs, and additionally extended to arbitrary trading strategies with some careful limitations associated with code execution. Again, because all of the risk ratings and user choices are relative and local and specific to each user's portfolio, this fits naturally into the localized model introduced earlier.

The most obvious tangible benefit to these models, besides just for diversification, is to avoid the realization of capital gains taxes. Arbitrary portfolio target contract strategies, for instance, adjusting the weighting of Bitcoin holdings relative to USDC for instance, if the BTC drawdown is greater than 10% of a recent moving average. It would allow a single address contract holder to avoid having to swap their assets, in much the same way as an ETF functions, except against an arbitrary trading strategy. This provides real-world utility for traders designing strategies up-front, and allows long term holdings that do not have the vulnerabilities associated with intense market volatility. Such strategies would gain the tax benefits of long term holdings, and prevent tax liability associated with frequent portfolio adjustments.

Another area of interest is in democratizing access to trading models. Numerai and other projects have attempted to incentivize the development of trading strategies by connecting them to a token, but there is plenty of room for development in this ecosystem for more sophisticated & decentralized strategies. The obvious barrier to entry associated with developing trading strategies is generally the cost of data & runtime execution. By decentralizing the work and relying on open-access data, it opens new opportunities for model development not conventionally possible without access to significant capital investments, as well as providing an incentive model for developers to be rewarded for their efforts.

Data Pipelines

While the above use case demonstrates the benefits of localized scores, there is a more generic expression of decentralized applications which demonstrates the benefits of localized concurrency primitives. SQL operations (relational algebra) & pipeline flows are a better way to describe distributed peer to peer applications as they solve the scalability problem more directly.

Contrary to the common and traditional use case for pipelines, which is batch analytics, many modern real-time services are backed by big data platforms like Spark or Flink or Beam or Snowflake. The most common use case for most applications is querying a database, applying some business logic, and then updating a database. This is core to most service implementations, and does not necessarily require 'big data' style tooling, but does benefit from it. The proliferation of microservices has lead similarly to orchestration problems in service calls, which end up sharing a great degree of commonality with pipeline style architectures, where dependency graphs are critical to expressing the underlying business logic. The generic abstraction of interest here is in isolating the raw data sources, and the sequence of query plans and transformations applied to all data sources of interest in producing the result of a query, and then updating them.

Blockchains in general are very commonly described as a multi-user, decentralized, distributed database. And it's an appropriate description. Applications then should be considered merely as shared logical transformations and operations upon this database, and borrow from concepts associated with pipeline architectures. In general, translating relational algebra (SQL query plans & UDFs & corresponding business logic transformations) to an untrusted decentralized context is an extremely difficult problem. It's exacerbated even more-so by the concurrency issues associated with global state aggregation -- which imposes a blocking constraint of the entire network preventing unrelated updates from being independently performed. Instead, the earlier described model naturally assists in solving this problem by isolating application flows in terms of their logical causal dependencies and translating the query plans into operations that can be performed against a fuzzy context.

Here is where there is a divergence from a conventional partitioning structure as seen in conventional 'big data' systems or large distributed databases. Because the most desirable network is composed of a large number of peers of potentially uneven sizes, (i.e. not all supercomputers,) executing potentially unevenly sized tasks -- and we can not constrain those peers to operate on a partition id determined by a central coordinator -- all logical operations must be translated to a context where they are available not on partition id, but hash distance.

This is not necessarily a problem, as we are expecting the overhead associated with running a function many times (due to the constraint of requiring multiple peers to validate a given operation,) adding the overhead associated with resolving data across potentially overlapping or uneven or unknown partitions based on hash distance is simply a negligible loss realized in the form of data potentially not being available on a given peer and a retry being required.

This constraint is modified in the event of long-term index style storage. While real-time operations must happen on a hash distance associated with the hash of an individual data item or transaction, index operations can support regular partitions, for instance a 50MB parquet file which represents indexed long-term storage data, represents a conventional partition. In this case hash distance is applied to the determination of which partition ids should be stored by which nodes.

The benefit of this approach, compared to something like the EVM, should be evident in terms of concurrency and optimization. Rather than expressing an application as a persistent state & storage with functions attached, from which all operations are co-mingled as updates, we express it in terms of the logical dependencies, data sources, and transformations applied to them. This means there is no single 'live' contract, but rather a series of events which can potentially apply changes resulting in new states. It also replaces the issue of function delegation with one of orchestration & chaining of pipeline transformations.