Code is Law, Hardware is Code's Language

CodeLawHardwareLanguage

The Law of Law is language. If your language is richly metaphorical and contains the word "schadenfreude", you will annex the Sudentenland, gas most of your Jews, while another Jew will use your language to express general relativity. A linguist will tell you all languages can express all concepts - languages are Turing complete - but this fashionable conceit does not tell us why different cultures do different things.

Code is law. Hardware is the law of code. Code can only do what hardware permits. A Turing complete machine can manufacture any set of symbols out of any other set, but those symbols cannot go where the hardware doesn't connect.

I realize, decades later, that I made one of the architectural decisions that allows the NSA to watch you as you read this webpage.

I designed a chip, a non-blocking crossbar routing device, for the startup I-Cube Design Systems in 1990. This chip routed signals from any pin to any other pin, and could route 240 inputs to any combination of 240 other outputs. But it also had fanout - it could route an input to two or more outputs. 160 inputs could become 320 outputs. This was useful for the original task - hardware logic simulation. When the original logic simulator customers became enmired in patent lawsuits, I-Cube found a new customer, another startup called Cisco. Cisco's routers distributed the backbone of the early internet, and still do most of it.

Cisco's routers flowed bitstreams, not "packets", a software metaphor for a time-bounded sequence of bits. Packet headers told the router which flow got the bits, the router told the crossbar device which path the bits took. Sending the bits to more than one place was implicit in how the hardware worked, because the hardware had fanout.

Cisco remains, I-Cube was killed by incompetent venture capitalists. I'm not party to how Cisco designs routers today, but fanout is implicit in dataflow, hardware can stream one transmitter to multiple receivers, tracelessly.

Software is merely "judicial opinion" applied to that hardware, and we non-electrical macroscopic human beings only have opinions, not sure knowledge, about how the bits are actually moving and transforming from memory location to other (possibly multiple) memory locations.

Software can encrypt - or it can pretend to. Software becomes machine instructions via a compiler. Dennis Ritchie taught us that a compiler emits machine instructions chosen by the compiler author, who can override the decisions of the source code author. The hardware author can override both. The hard disk manufacturer decides what firmware bytes go on the boot tracks of your hard drive, the disk firmware decides what bytes you actually get from which disk track, and this firmware is invisible to the software it dispenses. In an age of Viterbi coding and VLSI disk chips, even a hardware logic analyzer may not tell you what's actually on the boot tracks. For sure knowledge, you will need your own hardware, either your own replacement disk chips or a focused ion beam milling system to take apart the disk chips and learn how they work.

The economics of chip production make it impossibly expensive to give everyone a different chip architecture, while cheaply individualizing every chip (another of my inventions, see http://siidtech.com ). If there is a ghost in the hardware machine, it is in all the machines, and those versed in VLSI, equipped with FIB, can find the ghosts. The individuality can be perfectly hidden. Puzzling out a proprietary design is time consuming but possible, perhaps costing as much as the original design. Verifying that an open source hardware design is faithfully replicated in hardware is relatively easy, and could be automated. We do not do so, because software designers pretend the substrate does not exist, or is logically identical to all other substrates, and thus not worth controlling or verifying.

Open source hardware can also encrypt, and properly-designed hardware can encrypt without fanout (no feasible side channel attacks). If we choose, we can build individual hardware that encrypts each keystroke and decrypts it at each screen, whether the path is centimeters or megameters in between. You can use Gmail for your mail host, but your messages are gibberish to Google, and to whoever they share the messages with. Google banner ads can be ignored by your decrypter.

Hardware geeks will still need to re-examine (identical) copies of the hardware from time to time, to make sure the hardware matches specification, and crypto geeks will need to frequently re-examine the specification to make sure it is mathematically correct. And sometimes the hardware will be invalid, and we will need to replace it with new hardware. But a billion transistors costs pennies from Intel, which Amazon can get to you overnight.

Why this matters to Server Sky

Server sky will use far fewer routers. Access to server sky arrays will be trigonometric, not packet routing via DNS and routing tables; if the array is above the horizon and has what you want, you can talk to it directly without intermediaries, and your conversation can be encrypted end-to-end. Of course, each end can have fanout, with either the orbiting array or your ground terminal copying your conversation to your Designated Overlord. Each end can have a fanout of zero, censorship applied by that same (or different) Designated Overlord. No man-in-the-middle attacks when there is only vacuum and Maxwell's equations between sender and receiver, when orbital mechanics, Doppler shift, and twelve-nines-accurate shared clocks provide link authentication that cannot be spoofed without reshaping space-time.

There will be Designated Overlords - in the US, we call the overlords "Google" and "Hollywood", in China the overlords are the Communist Party and/or the People's Liberation Army. People can't seem to live without chains, sigh. But we must design our hardware so the overlords are explicit in the design, few in number, and subject to social opinion (which is more true for China than the US).

This matters because we are making the design decisions now that will shape the hardware for decades and possibly centuries, until the next big hardware shift. These decisions should be informed by every capable brain on the planet. They should not be made by me, nor by me and a handful of smart collaborators. The best minds work elsewhere, and the best minds, if they know what's good for them, will get involved while the future is still conceptual and easy to shape. After launch, we can still replace all the satellites and all the ground terminals and all the end-user gear, but inertia will make this very costly, and even the best minds don't have the money and persuasiveness to make this happen often. Better to get it approximately right the first time.

This webpage is an appeal for help. I beg you to help design the future you and your descendants will live in. I goofed up once, I would rather not do it again.