16 KiB
Simverse III
-
Author: u/krakonfour *
-
URL: https://www.reddit.com/r/rational/comments/2bei2v/simverse_iii/
-
Score: 7
-
Created: 2014-07-22T15:36:21
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 [+2] (5 hours later)
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.)
u/krakonfour [+1] (5 hours later)
Two reasons why that wouldn't work, before I get to the subject of further hacks in Simverse IV:
-The simulator has limited resources available. While it can handle a hack from a single ship, it would be difficult to accommodate 3 million new realtime zones to fully render, much less the googol^googol that follows. You'll crash the simulation in literally a fraction of a second.
-To duplicate 2^3,000,0000 entities, you're going to have to find 2^3,000,000 rendered sectors. I mentioned that an 'empty swap' doesn't work.
u/Gurkenglas [+1] (5 hours later)
You mean, the simulator on our host universe would need a nigh-infinite time before we observe a minute having passed? Oh no ;)
As for there not being enough sectors, eh, all of the sectors outside the inner solar system will suffice.
u/krakonfour [+1] (5 hours later)
Well, you'd think you'd have enough volume, but the smallest sectors are 125,000m3 and they reach 1,000,000,000m3 near the edge. Given an average of 500,062,500m3, you'd need a sphere, well...
The universe contains about 2.34x10e33 cubic light years, and it is a tiny fraction of the figure we're talking about.
u/Gurkenglas [+1] (6 hours later)
No, I mean I will be content with whatever amount of sectors the universe can come up with. I still have enough computing power to, say, manually run the incomprehensible code that runs the sector that contains my brain for a while to come up with more plans.
u/AmeteurOpinions [+1] Finally, everyone was working together. (10 minutes later)
Very cool. I'm looking forward to the next part.
u/Nepene [+1] (6 hours later)
How fast can you swap?
Could you swap a memory card between two zones say? Swap it into a large off ship quantum computer, get it to do calculations, swap it back, read off the results. A way to boost your computing power over enemies.
u/krakonfour [+1] (6 hours later)
Beyond a certain distance, you can swap as fast as your computer allows you to.
The problem with your method is that
A) You can only swap whole sectors. Unless your memory card is one hundred thousand meters cubed, there is no point in doing so.
B) The only useful pre-calculation is when you are trying to guess the coordinates of a sector outside of your realtime zone. Inside that zone, you can read the coordinates off the sectors around you directly, calculate the hack and apply it much faster than you could by transmitting it and receiving the calculated information at the speed of light. Plus, you can't read coordinates outside of your own realtime zone, so it is limited in that aspect.
u/Nepene [+1] (7 hours later)
Maybe have a tether behind the ship with a sensor on it and a small computer preloaded with transportation stuff. It sends details of the code around you to another zone which is next to a huge super computer. The super computer calculates all the details and sends the small computer back, and it relays the code.
I imagine you could use it for rapid ship to ship combat and teleportation. Jump in, see an enemy, teleport to a safe unrendered zone.
u/krakonfour [+1] (8 hours later)
Well, look at it this way:
Imagine we are in a sector where the simulation's attention window is 0.03 seconds.
Now imagine we have a spaceship with a poor onboard computer struggles to complete a swap in 0.03 seconds. There are three steps to a swap: reading, calculating and running. The first and second step are outside of the computer's control: they will always take 0.02 second.
Now the spaceship decides to use an external computer that can do the calculation part 10 times faster: 0.001 seconds.
The swap now takes 0.01+0.001+0.01: 0.021 seconds, right?
No. You need to send information to the external computer, then receive it back. Information travels at lightspeed. In 0.009 seconds, light travels 2700km, so the external computer must be within 1350km. That's basically dragging it along with you. Furthermore, there is delay involved in sending the information to the transmitter, and reading the information received. Each millisecond delay forces the external computer to be 300km closer... in space, you're practically dragging the computer along with you.
On top of all that....
The way swap work is that the hack is only implemented at the END of a rendering cycle. That means that even if you complete steps 1 and 2 as quickly as possible, you will be stuk loading for step 3 to happen. There is no point in 'going' faster' with such a hard limitation.
I'll talk more about how ships use these hacks and how they influecnce their design later.
PS: A bigger computer requires more energy and cooling, which basically means its a second spaceship in this setting.
u/Nepene [+1] (8 hours later)
The idea was that you'd the ftl power to skip the information travels at light speed. You are in zone 1, your relay computer is in zone 2 and is much smaller and preloaded with another location. You report a conflict, teleport the relay computer over, it sends light speed signals at the speed of light to the massive computer 50m away, receives signals, teleports back.
Clarifying whether this work is important for other things. If the rendering time is 0.03 seconds and you can cut it down to 0.02 then a third of the time you can teleport first, which is a huge advantage, though thinking about it the required times stop that. If it works it also means you can send ftl signals and teleport an army over, having given them your coordinates.
u/Laborbuch [+1] (14 hours later)
I assume the coordinates have to be calculated anew each time; you can't simply make a database with all the block coordinates you know already?
u/krakonfour [+1] (a day later)
Coordinates change constantly and dynamically: they adjust to your own realtime zone, and to information you can't perceive: realtime zones of other people, resources being diverted elsewhere, special verifications being run ect.
The only accurate reading is the one you do at the start of the hack, and is only valid for a handful of rendering cycles or less.