9.7 KiB
Simverse III
Post:
In this post, I'll reveal how HACKING THE UNIVERSE is done, which hacks can be done and which can't, and I'll expose a few more specificities of the setting.
As you can imagine, hacking is not a simple 'run the code on a computer' process. It takes requires three steps.
-The first is the equivalent of opening up a developer's console. A quantum processor must read a specific amount of data in the simulation's original language. This attracts the attention of the rendering engine: it opens up a window of time during which it 'listens' to instructions from the human computer. This window of time is equal to one rendering cycle, meaning you have anything between 1 picosecond and 1 year to complete the remaining steps for a hack. Usually, within the solar system, we're talking about 0.01 to 1 second windows.
The consequence is that hacking anywhere near a densely populated area requires extremely powerful computers and/or very simple hacks.
-The human computer now has access to the data stream the simulator uses to render the affected sector. The qubits do nothing except transmit this information to the regular computer. They're antennas. The data is they receive is shaped like an egg: a very thin shell of tangible coding, and a messy mush of incomprehensible code inside. To modify this code, the hacker has to find the start and end point of 'shell' code. At each end, he or she tacks on a specific code that basically says 'do not touch' to the rendering engine. It is the same code that the verification tool uses to prevent the rendering engine from modifying stuff in the sector while it is working on it. The sector is now invisible to the rendering engine, until the next verification sweep comes along and kicks you out.
-With the 'shell' code in hand, the human computer must now read it, decipher it and locate what can be modified. The rest is never touched. Once the code has been modified, the quantum computer re-reads the data from the first step. The simulation receives the instruction to open a new 'developer's console'. It is an impossible operation. The simulation ends both attempts and saves the modified code. It is applied during the next rendering cycle. The 'do not touch' brackets are eliminated during the next verification sweep.
So, to enable a reality hack, you must complete all three steps in the time it takes for two rendering cycles. The 'shell' code is about 10TB in size. That's not much compared to today's standards, but when you have to read and translate it in 0.01 seconds, you will need the equivalent of a supercomputer for each hack.
**To give you an idea of the timescales involved, here are a few more rendering cycle delays:
New York: 10e-30 seconds Marinas Trench: 10e-20 seconds Low Earth Orbit: 10e-15 seconds Lunar Orbit: 10e-5 seconds Asteroid Belt: 10e-3 seconds Oort Cloud: 10e-2 seconds Outside the Heliopause: 10e-1 seconds**
For a deep space trawler, a quantum computer with 1000 qubits feeding a machine running at 10THz and a memory being fed at 4TB/s. suffices Lots of T's, I know. The quantum computer only provides 'access' to the simulation's code, all the hard work is done by a regular computer. For a near-earth warship, a quantum computer with 10,000 qubits, 1000THz and 100TB/s is necessary. The simulator opens a much shorter window for the hacker to respond to, while the amount of information supplied by the qubits varies little.
Also, before we continue, I hope this image clears up a few things: How can humans and 'slow zones' coexist?
SO now we know that hacksare essentially tricking the simulation into reading your own modified data instead of the regular data. Remember resets? During a reset, the verification tool loads up a 'saved configuration' and replaces the current reality with the saved one.
Isn't that technically time travel?
*Not really. You see, I used 'saved configuration' instead of 'snapshot' because as the rendering engine works itself through a cycle, it saves only the barest of data. Just like recording a game, you'll notice that a video from the viewpoints of multiple players requires several gigabytes, while the 'replay' file contains all that information in a few kilobytes. The 'saved configuration' is that replay file. To reset, the rendering engine loads up the 'replay file', then applies the proper algorithms and rules as it would during a regular rendering cycle. The end result is a reality that looks like the error never happened.
With that out of the way, what exactly can you DO with these hacks?
The easiest and most common is the coordinate set. You read the 'shell' data, you find the coordinates for your current sector, and replace them with the coordinates for another sector. When the next rendering cycle arrives, the sectors will be swapped. Instantaneous teleportation!
This swap has many restrictions though. In deep space, where sectors are poorly rendered, the swap will be hard to detect for the verification tool. In a region filled with observers, there will be inconsistencies around the edges of the sector that will trigger a reset. Swapping multiple sectors as once also has the risk of triggering a reset. Within a sector, matter conserves mass and energy. Vectors are maintained relative to the center of the Earth (you cannot rotate sectors). It does not matter if the sector is filled with 1km cubed of gold or empty vacuum, the swap is just as easy. All that matters is the number of sectors being swapped, and how man observers there are inside the sectors affected. Even if the hacker orders the verification tool to turn a blind eye, the fact that a conscious being is being rendered in real time inside of the sector imposes a non-negligible stress on the simulator. A massive spike in resource requirements in an area that previously had very low requirements will trigger a reset despite the 'ignore' order.
The main use of CS (coordinate set) is travel. Once you are outside of lunar orbit, you can pretty much swap as fast as your onboard computer allows you to, enabling faster than light travel. If we imagine a hacker onboard a spaceship, he or she has access to information about every sector's coordinates within the realtime radius of the person occupying it. A spaceship can easily travel within its realtime radius because it only needs to read the coordinates of the local sectors once. On top of that, the realtime radius expands at the speed of light until it reaches its limit.
Sectors outside of the realtime radius must be guess-worked or the coordinates provided by an external source. If you swap into the orbit of pluto, through a correct guess, you will not be able to immediately jump around the area, despite the swap distance being much shorter. You'd have to wait approximately a third of a second for the radiations from your starship (light, heat, ect) to interact with the surrounding medium and enforce a realtime zone.
You cannot, however, swap with a sector halfway to Andromeda. That volume is not being rendered at all: there is nothing to swap with. If you force an 'empty swap', nothing happens, not even a reset. This is the next 'zone' that is mentioned in hacking. It is the indeterminate distance from the observer beyond which the simulation doesn't bother rendering at all.
It is possible, however, to swap with a sector nearby a hot star. The interaction between the star's radiation and the surrounding gas and dust forces a minimum level of rendering, providing sectors with coordinates you can work out how to swap with.
It is possible to artificially force the simulation to increase your realtime zone and the rendering radius by shining a light on the desired area. Heading into 'empty space' by shining a laser ahead of you is, however, necessarily slower than light.
Before I end this, I'll say:
Swap speed is determined primarily but how fast the onboard computer is.
It is also determined by how many sectors you swap at a time to teleport your spaceship, by how many people are onboard and by how well rendered the destination sector is.
Swapping two cubes instead of one is about 2 times slower than swapping a single cube, but swapping two people instead of 1 is 10 times slower (logarithmic scale). Rendering quality reduces the time it takes for the simulator to locate the destination cube and update it with the information you've added. A poorly rendered cube that has to be rendered to the quality of your sector takes longer than swapping with a well rendered cube of equal quality.
So, you can hop from one solar system to another in a fraction of a second, if you've got friends at the destination, but you can only travel into the unknown at the speed of your own laser flashlight. You can jump right next to a star light years away, but you can't jump past the Oorth cloud 50,000 AU away. You can follow someone swapping through space by targeting the realtime zones left behind after each swap, but you can't overtake without making an equally slow guess.
Next up is spaceship design and warfare.
After that, I will reveal another hack and the world's radically different economy.
Comments:
- u/Gurkenglas:
Hmm. Instead of swapping two sectors, could you copy the state of the first to the second? Exponential growth! You said that the verification tool checks on the oort cloud about once a minute, and that being outside lunar orbit (rendering cycle length up to 10^-5 seconds) gives you enough time to do a teleport, whose time requirement surely is on the order of a duplication. 3 million duplications and then 2^(3 million) spaceships doing whatever the hell you programmed them with for 30 seconds is surely an instant global victory condition. (Or just simulate your own sub-universe for longer than Gurkenglas' universe might have left to live.)