Our Computers

The goal of the Dauug series of computer architectures is to have zero exploitable hardware defects. Not zero known defects. Zero total defects. Computers that do exactly what they are programmed to do—nothing more, and nothing less.

Computers with zero security defects would have paradigm-changing properties. For starters, they would never need “security updates,” as there would be no defects to discover later. They would also be immune to artificial intelligence as an adversary, in the sense that if there are indeed no exploitable defects, no future AI will be able to discover a new defect to exploit.

Humans have used provably secure computers for thousands of years. A soroban is a digital computer, and no adversary across the ocean can remotely exploit one. Our problem now is that semiconductor complexity has become a profit center. Chips that are too intricate and opaque to audit are also too intricate and opaque to hold anyone accountable for losses from hacking and malware. Newly uncovered exploits create opportunities to sell the next generation of intricate, opaque silicon, so the incentives have never pointed toward fixing this.

Our Approach to Defects

Getting to zero exploitable defects takes a few steps. Not only are drastic reductions in complexity requisite, but the final design as well as construction and operation must be fully transparent. It’s not enough to have “many eyes” on a design as early open source proponents touted: the implementation has to be small enough that eyes are not fatigued. And because of the potential for maintainer fatigue, change is an enemy when defect counts need to be zero. It’s also not enough to have a secure design implemented as VLSI—the computer’s owner has no means to audit the delivered hardware to ensure it adheres to a design as claimed.

We hope to one day demonstrate using semi-formal or formal methods that our architectures are secure under defined conditions. We don’t have funding to start this any time soon. Our focus today is finalizing our computers in the simplest implementations we can make practical. We look forward to some near-term scrutiny of our computers through the use of generative AI, which has lately found use identifying bugs in software. Having said that, we do not view bug-hunting as a sound foundation for security, whether or not AI facilitates it.

Our Approach to Building Computers

We’ve ruled out using complex VLSI in our computers: we can’t use microprocessors, FPGAs, PLDs, ASICs, or DRAM. But there is a useful class of VLSI that is not complex, just very repetitive, and this class is synchronous static random-access memory, or SRAM. Unlike complex VLSI, SRAM is essentially generic, fungible, nonproprietary, standardized, simple logically, and clean semantically. We also considered VLSI memory’s indispensability in any useful computer today—without it, a million bits of storage would require about a million parts. And SRAM is the simplest way to implement VLSI memory.

Having established that SRAM is both acceptable and mandatory, it would make sense to find a way to use SRAM as a foundational logic gate to reduce the number of parts needed to realize a discrete-component computer. This was the subject of Alpha Dauug’s Ph.D. dissertation (2022), which showed that robust computers could indeed be built using SRAM as their principal logic family. Literally just a handful of chips are necessary, meaning that unlike the 1960s when discrete-component computers weighed hundreds of pounds or more, a modern SRAM-based architecture can fit on one circuit board and still be fully inspectable at the logic gate level.

Benefits and Tradeoffs Common to Dauug Computers

The logic of Dauug computers is assembled at millimeter scale instead of nanometer scale. There are strengths and tradeoffs to this approach. The upside is that only maker-scale tools are required: boards can be assembled either in a reflow oven or by hand soldering. After assembly, all connections remain exposed for visible, electrical, and/or X-ray inspection. No proprietary parts are used, and the output product can be audited for design conformity. The owner can directly, personally control the supply chain in a manner that would be impossible for traditional computers. And compared with traditional computers, Dauug’s circuits are dead simple.

The principal tradeoff to building at millimeter scale is the constraint imposed by the speed of light. Data processed in Dauug computers must travel much farther physically relative to data processed in a microprocessor, slowing the system down a hundredfold or more. Simultaneously, Dauug computers are orders of magnitude larger, heavier, costlier, and hungrier for electricity than traditional computers. This will be a deal-breaker for many applications, and we own that. On the other hand, there are perhaps as many other applications where Dauug’s dimensional disadvantages aren’t a problem at all, and these are the use cases where Dauug’s security benefits come into play.

Another difference that Dauug computers have to reckon with is their disuse of dynamic random-access memory (DRAM) in favor of static RAM (SRAM). SRAM is significantly faster, more reliable, simpler to interface, and eliminates whole families of exploitable vulnerabilities relative to DRAM. But SRAM makes a physical tradeoff in memory density that limits how much can go on a chip, and other market forces cause manufacturers to price SRAM chips at a high premium relative to their transistor count. Bit for bit, SRAM is often hundreds of times as expensive as DRAM. So between the size and cost differential, Dauug computers will have far less memory than traditional computers—another deal-breaker for many uses, but not a concern for many other uses.

Significant structural and electrical differences exist between Dauug architectures and traditional ones that make programming Dauug machines quite unlike prior experience. Many of these are due to the architectural simplifications our designs make to reduce complexity, improve security, and conserve speed. For instance, Dauug processors don’t need cache memory in the sense that ordinary processors do, therefore operating systems, certain programs, and cryptographers don’t have to do any work to accommodate a cache. Another example is that several binary counters in the Dauug architecture aren’t linear—they don’t count 0, 1, 2, ... as one might expect, and there are sound technical reasons for their difference. All told, these differences make the Dauug architectures distinctly their own; they will never be binary compatible with mainstream processors.

Building arithmetic logic units out of SRAM favors word sizes that are multiples of a perfect square, not multiples of powers of two. Thus Dauug|18 has an 18-bit word size (18 = 2 * 3**2), and Dauug|36 has a 36-bit word size (36 = 6**2), even though a traditional engineer would probably have sought 16- and 32-bit architectures instead. Indeed, the first machine Alpha Dauug set out to design was a 32-bit system, but he had to change it to 36 bits to make arithmetic work efficiently. It conveniently turns out that 18 and 36 are standard widths for SRAM chips because two sizes can cover four configurations: 16 bits, 16 bits and 2 parity bits, 32 bits, 32 bits and 4 parity bits. But Dauug’s unusual word sizes occasionally contradict assumptions found in the Rust programming language, standards for floating-point arithmetic, and elsewhere.

Because the various differences and tradeoffs increase friction relative to selecting and using Dauug computers, it’s important to remember their security advantages, which extend even beyond transparency of operation. The system owner controls the entire supply chain with respect to logic and behavior. Both Dauug architectures offer:

• Transparency of design and operation
• Owner control of all decisions pertaining to behavior and logic
• No DRAM or DRAM-associated vulnerabilities
• No VLSI complex logic except in attached peripherals
• No CPU persistent state except for one firmware IC
• No MEMS oscillator for age- and frequency-selected attacks
• No firmware modification without physical access
• No parts that can’t be hand-soldered and probed afterward
• No secret functionality
• No unexplainable S-box constants
• No vendor lock-in
• No encrypted or closed-source firmware
• No license fees to build, use, or modify
• No purpose-of-use limitations
• No planned obsolescence
• No right-to-repair infringements

Our flagship architecture Dauug|36 offers further security advantages relative to traditional CPUs that aren’t applicable to Dauug|18. We extend this discussion of Dauug|36 security features on our Q & A page.

Dauug|36: Our Flagship Computer

Dauug|36 is a transparently functioning, user-constructable, open-source, solder-defined, single-board minicomputer with 36-bit words, paged virtual memory, and preemptive multitasking. There is no physical prototype of the architecture yet because it is much cheaper to develop and test in simulation until a freestanding machine will boot and run. Once available, we expect that Dauug|36 will supplant Dauug|18 as the world’s most advanced transparently functioning architecture.

Because Dauug|36 cannot contain a microprocessor or anything like one, it must be built entirely from discrete components. Thus Dauug|36 is only suitable for select applications where performance, size, cost, and energy use are much less critical than absolute security and accountability. Its design is principally motivated by the needs of privacy seekers and critical infrastructure. The cost to build Dauug|36 will depend on supplier trends, global events, and access to volume discounts. The cost to build one machine, excluding tools and labor, will vary considerably and be on the order of U.S. $1,000.

Despite having a simple enough design for one engineer to understand and small enough form to build on a kitchen counter, Dauug|36 has architectural capabilities that are extraordinary relative to discrete component computers of the past and contemporary homebrew processors. Its instruction set already has around 190 opcodes and continues to grow. A comprehensive description of Dauug|36, its development, and its capabilities are available in this booklet by Alpha Dauug.

Dauug|36’s implementation of multitasking, paged virtual memory, and privilege mechanisms are distinct enough from mainstream architectures that it’s valuable to have a reference implementation of an operating system kernel to show how to employ these features securely together. To aid in this understanding, Alpha Dauug wrote Osmin, a real-time operating system (RTOS) kernel for Dauug|36. The Dauug|36 booklet just cited has an overview of Osmin’s present capabilities and remaining work (pp. 61–64).

Comprehensive documentation for Dauug|36 and Osmin is at 36.dauug.org.

Dauug|18: A Simple Controller for Invariant Code

Dauug|18 is a simple transparently functioning controller. It’s about one-fifth the size of Dauug|36 and might cost around $200 if just one is built, not including labor and tools. Unlike Dauug|36, which is designed to be a “general purpose” computer within its speed and memory capability, Dauug|18 is designed to be as succinct a CPU as we know how to design without crippling it for lack of bits.

Like Dauug|36, Dauug|18 is not ready for a physical prototype yet.

Dauug|18 has 18-bit words with separate 18-bit address spaces for code and data, constraining memory capacity harshly. There is no control decoder. Instead, what should be microcode forms the actual executable code. Although instructions take only one clock cycle each, it takes many instructions to accomplish much of anything. For example, 18-bit addition strictly takes two instructions, but the task is complicated because Dauug|18 has no registers. Fetching operands to add and storing the result increases the task of adding two numbers to seven instructions. And so on. Relative to Dauug|36, where assembly language programming is a breeze, Dauug|18 is a bear to code for.

Dauug|18 has no memory protection, no paging, no multitasking, no privilege concept, and no way to programmatically alter code memory. You can’t “start a program” on a running Dauug|18; whatever is running now is the only program that can run. Notwithstanding all these limitations, Dauug|18 may be the world’s most advanced transparently functioning computer when it becomes available. More or less by forfeit—the bar is very low today.

What Dauug|18 is good for is service as an embedded controller for infrastructure- and privacy-critical uses. The main requirements are that (1) dimensional constraints such as speed, cost, memory, size, weight, power are all met, (2) the gadget always powers up into a single application that doesn’t need to change. Of course it is possible to change Dauug|18’s firmware to run something else, but hardware to do this would be an add-on or temporary connection instead of built in.

Preliminary notes on Dauug|18’s logical implementation are at 18.dauug.org.

Dauug|18 as a Dauug|36 Coprocessor

Dauug|18 can support a broad range of uses, but it also plays two important roles in Dauug|36 minicomputers. The obvious one is I/O processing. Dauug|36 will support Serial Peripheral Interconnect (SPI) and Inter-Integrated Circuit (I2C) buses for peripherals. Because data will be transferred serially, either the Dauug|36 CPU has to take time out to exchange data a bit at a time, or another circuit has to transfer the bits so the CPU can do more valuable work. Dauug|18 was designed expressly to meet Dauug|36’s need for a separate input and output controller.

The less obvious use for Dauug|18 is powering up Dauug|36. The basic logic gate in Dauug|36 is an SRAM chip, but SRAM retains no data without power. When power is applied, Dauug|36 has logic gates, but they contain no logic, meaning Dauug|36 isn’t yet a computer and can’t assist in becoming one. Firmware must flow from external storage into more than 20 SRAMs before Dauug|36 can think, and the paths and steps involved are complex enough to call for a controller approach rather than simple non-SRAM logic gates. There’s already a Dauug|18 on the board to handle I/O after startup, so it’s available beforehand to load the Dauug|36 firmware. It’s a perfect use case for Dauug|18 because the only code it will run won’t change, and all that code will do is load firmware and marshal I/O.

Dauug|18 is itself an SRAM computer, so when its power comes on, its SRAM gates also contain no logic and therefore the system isn’t a computer and can’t assist in becoming one. To break the impasse, the Dauug|18 will contain some brute-force wired logic—NAND gates, flip-flops, that kind of stuff—that will partially load the five SRAMs that need firmware. The Dauug|18 will then use its incomplete but Turing-complete logic to finish its own firmware load, and then it will be able to move firmware into the Dauug|36. The benefit of using Dauug|18 as an intermediate is that its initialization is far simpler to do using basic components than Dauug|36 initialization would be.