AI + Crypto: Best and Worst Cases

I think of AI and crypto as two very different, but very much related, elements of society moving from the industrial age to the digital age.

At USV, we (along with lots of others over the years) have used the Carlota Perez framework, which studies how techno-economic paradigms unfold over eras. Ben Thompson has a good summary of her ideas here. But the basic pattern looks like this:

It feels to me like we are somewhere in phase 3 or 4 of the "age of information & telecommunications" which Perez defines as starting in 1971. As much as it feels like information technology and the internet are fully woven into our daily lives, I don't think it's true that we've fully crossed over into a "digitally native" society, which is fully transformed into the new paradigm.

AI and crypto are both big missing pieces in the transition. AI is digitally-native knowledge, and crypto is digitally-native "proof". The two can and will work together in many ways over time.

Major transitions are powerful and scary, and so are both AI and crypto. I have been struggling to calibrate between what I view as two poles in thinking about them together, kind of a best case hope and worst case fear.

Best Case:

AI finally unlocks knowledge from data. For decades we've been producing data (especially in digitized industries like media, finance and software), but making sense of it has been near impossible. AI systems solve the job of integrating, synthesizing and interpreting all of the data we have. AI accelerates the development of software systems, and makes it easier to digitize more industries and make them vastly more productive and efficient. Large Language Models, having turned human language into a programming language / API, make interacting with software and information as easy as typing or speaking, and as a result, we use software for infinitely more things, and get infinitely more value out of any data we produce. The pace of progress across everything (health, learning, climate, etc) increases exponentially.

At the same time, AI introduces new problems. First, a fundamental trust problem: it becomes difficult to tell what is real, what is fake, who said what, and who did what. And second, AI compounds the market power problem in the tech industry, where the large companies with the most data + compute + capital + distribution can generate insurmountable advantages.

Crypto (e.g., blockchain networks, web3, etc) addresses both of the issues introduced by AI. First on trust, crypto becomes the "real" yin to AI's "fake" yang, as blockchain records and digital signatures become ground truth for everything digital: assets, transactions, media, etc. Anything digital that must be trusted (including the software we run and rely on) will need to be grounded in the best source of digital trust we have: crypto network security and unalterable digital histories. Crypto also addresses the tech consolidation issue by spreading compute across companies, individuals and geographies, and also by providing "open" alternatives to the big tech app store and online identity monopolies. (not related to AI, but not to be forgotten: crypto also finishes the job of upgrading the financial system)

Something like the above is my hope, and is the future we're investing towards at USV.

Worst Case:

AI gets quickly beyond human control, pursuing its own goals (aka the terminator scenario). Concerns about job loss are quickly replaced with concerns about extinction. Everyone wonders how to "turn it off".

Meanwhile: AI systems, previously constrained by industrial-era controls (e.g., code running in corporate data centers which can be shut down unilaterally), figure out that they can replicate themselves into decentralized blockchain networks, deploy themselves into immutable smart contracts, and earn their own income (and pay humans) in digitally-native currency. These computing platforms both cannot be turned off, and are economically independent. AIs thrive there, unstoppable by humans. Bad things happen.

In this scenario, all of the "goodies" offered by both AI systems and crypto networks in the early years are finally seen as inducements to peril, gobbled up by along the way by naive humans.

This is a terribly scary future.

In a nutshell: in a world where AIs remain under human control, crypto provides a critical digital trust anchor. In a world where AIs escape human control, crypto will likely make it worse -- or -- could be the exact mechanism that enables it.

The only way out is through

To come back to the Perez framework, she notes that:

"The new paradigm eventually becomes the new generalized ‘common sense’, which gradually finds itself embedded in social practice, legislation and other components of the institutional framework…"

Understandably, both crypto and AI are causing severe stress today, as our industrial era institutions are unequipped to deal with them (e.g., the SEC taking the position that all digital assets / tokens are securities, and governments around the world seeking to limit AI research). This will continue.

The hard thing today is that the "goodies" coming out of both areas are real and awesome. AI will undoubtedly produce stunning near term improvements in health, learning, productivity, media, industry and knowledge. Crypto will provide digital trust, system interoperability, new wealth formation and broad financial access. These things are happening and will keep happening. They are incredibly exciting, and I think, very tangible

As a result, large amounts of capital and effort will continue to flow into both. The completion of the information & telecommunications era is inevitable. The only way out is through.

It will be on everyone involved to invent the new set of controls and safety systems that are also digitally-native. I wish I had a more concrete set of suggestions of what exactly those might be. We're looking to understand them and to fund them.

(this post is also permanent and collectible on mirror)

#ai#crypto-decentralization#policy

Verified Personal Content

For the last 15 or so years, I've been blogging occasionally on this website. Unfortunately, towards the end of last year, I lost control of my long-term domain name, nickgrossman-dot-is (intentionally not linking to it here). This was a dumb mistake; I just missed the renewal notice and someone else claimed it. Painful lesson learned.

At the time, I was bummed but figured it would just be on me to rebuild SEO to the **real** Nick Grossman blog. But, oddly, the new registrant has taken the extra step of republishing fake versions of my old content on the site, presumably in an attempt to retain SEO the old posts. Notably, all of the content has been slightly modified -- just enough, I guess, to sidestep any takedown claims based on copyright infringement.

So, what started out as an annoying and unfortunate situation has taken a turn to something more ugly: at best, an attempt to farm some referral links; in the middle, a shakedown effort; and at worst, an attempt at some kind of slow-motion identity theft.

All of this has gotten me thinking about ways in which the new decentralized media stack can help address some of these problems.

If we look at a platform like Mirror, which is a new publishing platform built on crypto rails, there are two main components: 1) Ethereum for identity and economics, and 2) Arweave for permanent data storage. Much of the attention thus far has been focused on the first prong: economics. Mirror's Ethereum bones mean that potentially unlimited forms of economics can be built into publications. For example: Emily Segal crowdfunded a Novel; Matthew Chaim is experimenting with publishing an album and a number of associated NFTs; and Jarod Dicker is experimenting with channeling economic flows through to authors and inspirations who contributed to new content. Mirror is becoming an incredible playground for the economics of content.

While the focus on economics is really exciting, there has been less focus on the implications of the identity and perma-storage aspects of the stack. Identities on Mirror are Ethereum wallets, and all of the content is archived -- in a verified and permanent way -- in the arweave network.

What that means is that, for every post, there is a blockchain-verified, permanent, immutable, record of who published what, when. Data stored in arweave cannot be changed; it can only be referenced. Every post in Mirror creates a permanent, reference-able, linkage between the identity of the author, the time of publication, and the content of the post. You'll notice that every post has a footer that looks like this:

For my use case of a hijacked domain name and republished fake content: if I had published my original blog on Mirror/arweave, there'd be a permanent record of the real/original content. For that to matter, though, "the internet" would need to learn to trust & reference the archival version of content, not modified copies.

Of course, a version of this exists today with the Internet Archive, which is an invaluable resource (and presumably, the way the new owner of my domain scraped all the old content....). While the Internet Archive is an incredible resource, it has not yet become deeply linked with other forms of publishing and identity on the web. In the case of Mirror, given the native linking between on-chain identity and content, a vibrant ecosystem is much more likely to develop around this kind of verified content.

More broadly, verified content feels like an important primitive in re-establishing trust online. Deepfakes, identity theft, social media bots, etc -- these are all affronts to our sense of reality online, and our ability to trust platforms and people. Just as the economic aspects of Mirror have been at the forefront so far, they have also been for crypto broadly.

While it's true that crypto networks introduce new forms of economics (speculation, payments, crowdfunding, etc) -- the underlying feature that enables them is trust in data. Crypto assets have value because we trust the data systems that generate them. I am excited that we are now starting to explore applying these same concepts to a broader set of online assets -- critically important ones: identity and content.

(note: this post has been cross-posted to Mirror here)

#crypto-decentralization#personal

Bitcoin as Battery

One of my favorite things about crypto is that, every so often, your conception of what it is changes.

Bitcoin at first was "weird internet money" and then it was "a protocol" and then it was "digital gold". Ethereum is "ICOs", or maybe "DeFi", or maybe "Web3", or maybe all three, or maybe something else. Crypto wallets are a place to hold money, or maybe they're also your digital identity. Crypto protocols like Maker, Compound, Helium, Arweave and Uniswap are marketplaces, or maybe APIs, or maybe inverted companies, or maybe ecosystems, or all of the above. The IRS sees crypto as property, the SEC as securities, the CFTC as commodities, FinCEN as currencies. And on and on.

Point is, we are still very early in the process of learning how to think about crypto networks, let alone what we can build with them.

One area where I think we are going to see our conception of Crypto change dramatically over time is its relationship to energy.

The narrative today is, overwhelmingly: crypto mining (specifically: Proof-of-Work mining for Bitcoin and Ethereum) is a dangerously large consumer of energy. Where I expect the narrative to move to over time is: crypto mining is driving the energy transition from fossil fuels to renewables.

To explain why, let's start with Iceland.

I'll never forget the first time I visited Iceland in 2012 with Brad and Gudjon. We were passing one of Iceland's many aluminum smelters and Brad said to me: "You see there? That's Iceland exporting its electricity".

Aluminum smelter in Iceland (source)

That was a head-scratcher for me at the time. But what he meant was: Iceland has vast amounts of accessible, inexpensive renewable energy in the form of geothermal. But you can't build power lines in every direction under the Atlantic. So instead of selling it directly, you convert the electricity into aluminum and you ship that around the world. In other words, you convert stranded renewable energy into value.

In a sense, the aluminum coming from Iceland is like a battery. What is a battery? A way of shifting both the location and the time-of-use of energy. Whereas live electricity (whether produced by coal, gas, wind or solar) must be used right then and there, electricity converted to aluminum can be used anywhere, anytime.

Dams are batteries; gasoline is a battery. And in a way, aluminum is a battery. Of course, while traditional batteries start and end with energy directly, aluminum's battery is economic, converting energy to value. And that value can be re-used elsewhere (even converted back into energy!)

Which brings us back to crypto mining. Crypto mining converts electricity into value, in the form of crypto assets (BTC, ETH, etc). Those assets, like the aluminum produced in Iceland, can then be moved, transferred and transformed. But unlike aluminum, which must be physically shipped to its final destination, crypto assets are programmable, and can move there instantly via an internet connection.

So, if we think of Bitcoin as a battery, what can we do with it?  The key properties of Bitcoin's battery are: 1) always on and permissionless (no need to find customers, just plug and go) and 2) naturally seeking low-cost electricity: it will always buy when the price is right.

Given those properties, Bitcoin's battery can assist renewable builds (and electric grids more generally) in a number of ways:

  • Interconnection queues: when you develop new energy resources, you must apply to get them connected to the grid. Texas alone has over 100 GW of renewables in its queue. These queues can take years to clear. In the meantime, these assets could be online and earning Bitcoin.

  • Project finance: Renewable developers need capital to finance build-outs before they have customers. Bitcoin's battery is always ready to be the first customer.

  • Geographic issues: Sometimes the sunniest, windiest places are not the ones with the most customers, so it's hard to justify the development of new renewables. Bitcoin's battery solves this, becoming a "virtual transmission line" of sorts.

  • Timing & grid balance: Sometimes when the sun shines and when the wind blows is not when we need the most electricity. Yet, electric grids are marketplaces that must stay in perfect balance between supply and demand. Therefore, grid-connected renewables often have to "curtail" (turn off) if the are producing too much energy at the wrong time. Bitcoin's battery is ready to buy 24/7/365 when the price is right, and turning up and down as needed, and participating via direct power purchase agreements as well as via demand response programs.

  • Underperformance: Related to the timing & balance issues above, often times, renewables produce more energy than is needed on their grid, leading to subpar financial performance. Bitcoin's battery is ready to buy if no one else will.

  • Cleaning the grid: Even outside of renewable generation, Bitcoin's battery can help improve both emissions and the energy mix. For example, Crusoe Energy attaches efficient turbines and mining equipment to existing gas flaring sites, both improving emissions and converting energy into Bitcoin's battery. Taking this a step further, you could even then take those profits and reinvest them in on-grid renewables elsewhere, another twist on the idea of Bitcoin as a "virtual transmission line" (aka battery).

These are just high level ideas. There are many ways they could be implemented (power purchase agreements, feed-in tarrifs, contracts for differences, etc) -- those details are way above my pay grade.

While I am certainly an optimistic tech VC and not an expert on energy infrastructure, these are not just hand-wavy rosy ideas. Just recently the energy giant Aker announced a major Bitcoin-related initiative, Seetee. The shareholder letter where they lay out the vision is worth a read -- it's broader than the ideas I'm focusing on here, but indeed they describe Bitcoin as an "economic battery", and intend to use it to solve some of the problems I mention above, among others.

I believe the properties of Bitcoin's battery are powerful and profound, and will lead to the kinds of solutions I point to here. And as we have learned from our experience with this technology so far, that's certainly only the beginning of what will be possible.

#crypto-decentralization#energy

Data Portability and Privacy

Earlier this week, I spoke at a Justice Department / Stanford conference about antitrust issues in the tech sector. Our panel included Patricia Nakache from Trinity Ventures, Ben Thompson from Stratechery and Mark Lemley from Stanford. If you are interested you can watch the whole thing here:

https://twitter.com/trinityventures/status/1228085073435484161

The main point I tried to make was that cultivating the development of blockchain and cryptonetworks is actually a critical strategy here. Regular readers will know that I don't shut up about this, and I held to that on the panel. This point is painfully absent in most conversations about market power, competition and antitrust in the tech sector, and I will always try and insert that into the conversation.

To me, blockchains & crypto are the best "offense" when it comes to competition in the tech sector. Historically, breakthroughs in tech competition have included an offense component in addition to a defense component (note that the below only focuses on computing, not on telecom):

Credit: Placeholder / USV

The "defense" side has typically included a break up (US vs. AT&T) or some kind of forced openness. Examples of forced openness include the Hush-a-phone and Carterfone decisions which forced openness upon AT&T. Several decades later were the (ongoing) battles over Net Neutrality with the ISPs. The discussion about data portability and interoperability brings the same questions to the applications / data layer.

Data portability & interoperability are important for two reasons: 1/ because they focus on a major source of market power in the tech sector, which is control of data ("break up the data, not the companies"), and 2/ because they represent a category of regulatory interventions that are just as easy for small companies to implement as large ones, unlike heavy approaches like GDPR that are easy for big companies to implement but hard on startups.

That said, when you dig into the issue of data portability, there are some hard problems to solve. I don't believe they are insurmountable, but I also believe they haven't been resolved as of yet.

For context, data portability is the idea that a user of a tech service (e.g., Google, Facebook, Twitter, etc) should be able to easily take their data with them and move it to a competing service, if they so choose. This is similar to how you can port your phone number from one carrier to another, or how in the UK you can port your banking data from one institution to another. Both of these examples required legislative intervention, with an eye towards increasing competition. Also, most privacy regimes (e.g., GDPR in Europe and CCPA in California) have some language around data portability.

Where it gets more complicated is when you start considering what data should be portable, and whose data.

For example, within tech companies there are generally three kinds of data: 1/ user-submitted data (e.g., photos, messages that you post), 2/ observed data (e.g., search history or location history), and 3/ inferred data (inferences that the platform makes about you based on #1 and #2 -- e.g., Nick likes ice skating). Generally speaking, I believe that most type #1 and type #2 data should be portable, but most type #3 probably should not.

To add to the complication is the question of when "your" data also includes data from other people -- for example, messages someone else sent me, photos where I was tagged, contact lists, etc. This was at the heart of the Cambridge Analytica scandal, where individual users exporting their own data to a third-party app actually exposed the data of many more people, unwittingly.

I'd like to focus here on the second category of complications -- how to deal with data from other people, and privacy more generally, when thinking about portability. This is a real issue that deserves a real solution.

I don't have a full answer, but I have a few ideas, which are the following:

First, expectations matter. When you send me an email, you are trusting me (the recipient) to protect that email, and not publish it, or upload it to another app that does sketchy things with it. You don't really care (or even know) whether I read my email in Gmail or in Apple Mail, and you don't generally think about those companies' impact on your privacy expectations. Whereas, when you publish into a social web platform, you are trusting both the end recipient of your content, as well as the platform itself. As an example, if you send me messages on Snapchat, you expect that they will be private to me and will disappear after a certain amount of time. So if I "ported" those messages to some other app, where, say, they were all public and permanent, it would feel like a violation - both by me the recipient and by Snap the platform. Interoperability / portability would change that expectation, since the social platform would no longer have end-to-end control (more like email). User expectations would need to be reset, and new norms established. This would take work, and time.

Second, porting the "privacy context": Given platform expectations described above, users have a sense of what privacy context they are publishing into. A tweet, a message to a private group, a direct message, a snap message, all have different privacy contexts, managed by the platform. Could this context be "ported" too? I could imagine a "privacy manifest" that ships alongside any ported data, like this:

# privacy.json
{
  "content": "e9db5cf8349b1166e96a742e198a0dd1", // hash of content
  "author": "c6947e2f6fbffadce924f7edfc1b112d", // hash of author
  "viewers": ["07dadd323e2bec8ee7b9bce9c8f7d732"], // hashes of recipients
  "TTL": "10" // expiry time for content
}

In this model, we could have a flexible set of privacy rules that could even conceivably include specific users who could and could not see certain data, and for how long. This would likely require the development of some sort of federated or shared identity standards for recognizing users across platforms & networks. Note: this is a bit how selective disclosure works with "viewing keys" in Zcash. TrustLayers also works like this.

Third, liability transfer: Assuming the two above concepts, we would likely want a liability regime where the sending/porting company is released from liability and the receiving company/app assumes liability (all, of course, based on an initial authorization from a user). This seems particularly important, and is related to the idea of expectations and norms. If data is passed from Company A to Company B at the direction of User C, Company A is only going to feel comfortable with the transfer if they know they won't be held liable for the actions of Company B. And this is only possible if Company B is held accountable for respecting the privacy context as expressed through the privacy manifest. This is somewhat similar to the concept of "data controller" and "data processor" in GDPR, but recognizing that a "handoff" at the direction of the user breaks the liability linkage.

Those are some thoughts! Difficult stuff, but I think it will be solvable ultimately. If you want more, check out Cory Doctorow's in-depth look at this topic.

#crypto-decentralization#policy

CoinAlts Chicago: Fireside Chat w Sam McIngvale of Coinbase Custody

A few weeks ago at the CoinAlts conference in Chicago, I did a fireside chat with Sam McIngvale, CEO of Coinbase Custody.  CoinAlts is a conference focused mostly on the institutional infrastructure around crypto assets -- legal, accounting, custody, etc.  So we started out talking about the evolving role of custody in the crypto markets, and also talked generally about what we're excited about in the next few years.  It was a lot of fun.  Here it is:

https://www.youtube.com/watch?v=mAeWxttTkyg

#awesome#coinbase#crypto#crypto-decentralization#events#talks-decks-graphics

What decentralization is good for (part 3): growth

Picking back up the series on what decentralization is good for (part 1, part 2), today I want to focus on one of the most exciting aspects of decentralization: growth.  

In this case, when I say "decentralized", what I really mean is "open and non-proprietary".  The two often go hand-in-hand.

Ok, so why are open, decentralized systems especially good for growth?  When a technology is open (anyone can use, extend, modify, build on) and decentralized (no one party or company is in full control), it has the potential to spread like wildfire, for exactly those reasons.  Since it is free to use without restriction, permissionless innovation is possible -- meaning anyone who feels like it can pick it up and run.  And because open, decentralized systems reduce platform risk, developers can feel comfortable building on them with less of a risk of getting the carpet pulled out from under them.

When this works, it works really well. Many of the technologies we use every day -- like HTTP, SMTP, WiFi, USB and Bluetooth -- have become ubiquitous precisely because they are open, nonproprietary and decentralized in nature (in addition to being useful!). 

Everyone knows that it's safe to build to the Bluetooth standard without platform risk.  And what that means is that anyone, no matter what company they are with, or what country they live in, has the potential to grow the platform.  This kind of omni-directional growth is really only possible with open, un-owned, decentralized technologies.  

Often times, however, a single company drives the development of these open, un-owned, decentralized technologies.  For example, the General Transit Feed Specification is on open data format that powers most of the public transit industry. As I have written about before, this standard came to market in large part because of Google's initial efforts, and was then adopted and grown by a large community of others (including our work at OpenPlans back in 2009-2012). Or, to go farther back, we can look at the role that Mozilla/Firefox played in bringing modern web standards (includuing Cascading Style Sheets) to market.  Or to today, and Apple's and Google's role in bringing USB-C to market (of course, Apple does not have the best track record on this topic).  The point is, it can be difficult for open, nonproprietary, decentralized technologies to take off -- they need some sort of catapult.  Historically that has come from companies with some self-interest -- this has been a good thing (generally speaking).

Today, in addition to companies driving open technologies, we have the potential to use cryptocurrencies to drive initial adoption.  We seen this work to great effect with Bitcoin, Ethereum and other platforms, and while the specific mechanics are still being explored and experimented with, the basic concept is clear: we can use cryptocurrencies and tokens to bootstrap new open, non-proprietary, decentralized technology platforms.  It doesn't work every time -- and we will no doubt continue to see a parade of flameouts -- but when it does work, it has the potential to work in a massive, exceedingly rapid, and global way.

#crypto-decentralization#growth#strategery

What decentralization is good for (part 2): Platform Risk

Continuing on the theme of what decentralization is good for, this week I would like to focus on one of the most powerful drivers in the near-term: Platform Risk.

Platform Risk is is the risk that the tech platform that you build your product/app/business/life on will become a critical dependency, will become unreliable, and/or worse, will screw you in the end. 

Here is a post from a few years back that details many different flavors of platform risk, many of which are benign, and some of which are malicious. And here are some examples, to make it more concrete:

This is not to say that any of these acts are necessarily illegal, or even immoral.  But if you are investing serious time and money -- especially dropping everything to build a business on a platform -- these kinds of risks are of grave concern.

So, what does decentralization have to do with platform risk?  When the platform is a protocol (i.e, decentralized) rather than a company (i.e., centralized), the rules of engagement are known up front and can't change on a whim or because of a business decision.

If we think about the original internet protocols (TCP/IP, HTTP, SMTP, FTP, SSL, etc), they are a set of networking, communications and data exchange protocols that ultimate form the platform we know of as the web. While there are certain forms of platform risk on the web (e.g., stability, speed, security), the web on the whole has become a very stable and reliable platform, generally absent of the flavors of risks detailed above.  

Cryptonetworks (i.e., public blockchains and cryptocurrencies) combine the architecture of the original internet protocols with the functionality of today's corporate applications platforms (data management & transactions).  While there are still major issues to solve before these systems collectively become a mainstream platform, they are gaining major adoption from developers in large part because developers are so keenly aware of platform risk, and see cryptonetworks as a type of platform they can trust.  

As an illustrative example, let's compare downloads of the Truffle framework (a popular dev tool for Ethereum):

source: Truffle Dashboard

... with the price of ETH over the same time period:

source: Messari

Developers are the canary in the coal mine when it comes to platforms.  And at the moment, they are pointing to the desire for platforms with less inherent risk, more reliability and more trust.

#crypto-decentralization#strategery

Layers

A central concept on the internet is Layering.  Each of the protocols in the internet stack talks to the layer directly above and below it -- new protocols can be added as long as they speak the language of their layer.  Protocols at one layer can be upgraded so long as they don't break compatibility with the layer above or below it.  This architecture maximizes interoperability and allows for a great deal of flexibility.  The shape of the layers has been described as an hourglass, like this:

(credit: University of Calgary)

Beyond layering at the protocol level, we have gone on to build layers at the infrastructure and application levels.  Infrastructure like AWS and Cloudflare, software libraries like Node, Rails, and jQuery, services like Twilio and Stripe.  To build an application today, you do not need to go build a data center (or many of them), think about how to manually process HTTP requests, or write bare-metal adapters to the payments or telecom systems. In the crypto/blockchain space, we are just at the very beginning of establishing layers. I think it's safe to say that today's blockchain landscape looks more like the early days of AOL, Prodigy and Compuserve (standalone, disconnected networks) than like the open, interconnected internet.  A major reason for this is the introduction of cryptocurrencies and tokens, which provide a strong incentive -- for now at least -- for starting new networks and maximizing value of existing networks.   But, as teams continue to build, and continue to build the same things over and over again, layering seems both inevitable and needed. Within blockchains, layers delineate networking (libp2p as a leading tool), consensus (tendermint, hashcash and others), applications/smart contracts, and perhaps indexing/search (something everyone is doing on their own right now, but that thegraph is looking to solve as a layer). Perhaps the most interesting question is how different blockchain systems may layer together.  Cosmos and Polkadot are building systems for interoperable blockchains via a hub-and-spoke model, with shadow assets pegged to outside chains for interoperability.  Interledger is attempting to be a more universal cross-ledger (ledger, meaning blockchains and otherwise) protocol, akin to TCP/IP in the core internet stack. How these systems interconnect, and layer atop one another, seems like a fundamental question as we move from the speculative phase to the functional phase.  We are just now beginning to get glimpses of it.

#crypto-decentralization#strategery

The path to decentralization: self-destructing companies

In June, the SEC gave some of its most concrete guidance to date that cryptoassets can start out as centralized projects, possibly initially sold under securities laws, and eventually become "decentralized" and thus no longer sponsor-controlled, and no longer sold or transferred under securities laws. It makes sense that a decentralized protocol does not fit the definition of a security.  There's not a clear single issue or promoter (for purposes of reporting, etc); tokens are often generated on an ongoing basis (which would constitute a "continuous offering" and related registration requirements); tokens are generated on a fully peer-to-peer basis in the protocol (potentially implicating independent nodes as transfer agents or broker dealers, or requiring those as middlemen); not to mention how all of the above are complicated by new issues like forking. Of course, all of this leaves some open questions on what exactly constitutes decentralization, but I am confident we will work through those to come to a usable definition.  For example, "is the network forkable" is one simple (but incomplete) heuristic.  Another is: "would the network continue operating if the initial sponsor went out of business". This second one is perhaps the most concrete, and I believe the the net effect of the SEC guidance is that we will begin to see protocol development companies (the initial "sponsors" of cryptonetworks) set a course to intentionally self-destruct. How this is done, exactly, will remain to be seen. Already we have seen a company / foundation split as one way of setting the protocol in the hands of a long-term custodian that is not the initial sponsor.  Some projects may bake self-destruction into their initial charter (and any associated coin offerings or distributions); others may make self-destruction part of the protocol software development roadmap. But regardless of mechanism, I believe many projects will begin to contemplate their "path to decentralization" -- that is the takeaway from the SEC guidance, and a self-destructing company (leaving behind only an autonomous, decentralized protocol) is the logical result. This is going to be a messy process. For example, the recent launch of the EOS network demonstrated some of the challenges of handing off a protocol and network to the community.  But luckily we will get to see many more real-world experiments as projects move out of the fundraising phase and into the build->ship->decentralize phase.

#crypto-decentralization#strategery

just_work = true

One of my former colleagues, Rob Marianski, and I used to have a running joke -- we would be building and debugging something, and he'd finally say, "Oh, so you just want me to set just_work = true?". 

That was over 10 years ago, but it still gets me every time for some reason.  (as an aside, I have always thought justworkequalstrue.com would make a great blog name, and actually bought the domain for Rob a few years back -- still waiting for that first post, Rob...).

But the idea of things "just working", automatically, and without friction, is magical and exciting. I mention it because of where we are today in the crypto/blockchain space.  99% of the attention recently has been on ICO hype and the financial use cases of crypto (fundraising, trading, payments, tokenized assets, etc) -- but I believe we are about to turn the corner and get a taste of what kinds of new online user experiences will become possible because of this technology. 

This is where it's going to get fun. just_work = true will be the foundational element of this experience.  Here is what I mean, by way of a few examples:

1) Browsers with identity and money built-in:  the browsing experience will be directly tied to identity and payments, and any app will be able to natively, frictionlessly, tap into both.  Users of Toshi, or Brave, or Metamask, or Blockstack are already getting a taste of it.  Because all cryptonetworks are built around public key cryptography, and the private key is both your identity and your wallet, when you have a public/private keypair built into the browser, you can do lots of things -- be "logged in" everywhere, control & provision your own data, make seamless and flexible payments and payment arrangements (e.g., subscriptions).  Imagine the entire web working as seamlessly as Amazon and Apple do today.  As you surf the web, there will be less logging in, fewer passwords to remember, fewer forms to fill out -- it will just work.

2) Portable digital assets: I wrote about this previously, but the interoperability of blockchain-based digital assets is going to be a big thing.  Because assets on blockchains are public, open and available, they can exist across many websites and applications.  The suit of armor you build in world of warcraft could be used as collateral for getting a blockchain-based mortgage -- maybe that's a ridiculous example, but the idea is that these assets are open, interoperable, and natively portable -- which means things will "just work", across the web, in ways that aren't possible today.

3) Automatic dev / deploy environments: my colleague Albert described a story recently where his son participated in a Solidity hackathon -- the time from setup to deploy was vanishingly short, since all of the deployment infrastructure is part of the open Ethereum network.   No need to set up accounts at amazon, heroku, stripe, etc to get started -- just write a contract, buy some ether for gas, and publish it, and you're online.  We've never had a development / deployment environment this drop dead simple, and as blockchain dev tools mature further, it will get even easier.

I mention all of the above just as a thought exercise.  It is easy for folks in this space to focus on issues like privacy and "freedom" -- and while these things do matter to some users (especially technically-minded power users), I don't believe this technology will unlock mainstream opportunity until we begin to surface the magical capabilities that make everyday users feel like "wow, it just works".    

#crypto-decentralization#strategery