How does a computer chip read code, interpret it, and convert it into action?
In order to understand how to build a computer, engineers divide its operation into layers, to limit the complexity. Each layer relies on the operation of the layer 'below' to provide services to it, and provides services to the layer above. When a designer is working on a design, he usually only thinks within one layer. Each layer will have a different vocabulary.

The fact that you've used 'instruction set', 'voltage' and 'high' in the same sentence means you're trying to think across several layers at once, which we just don't do. It's not only too complex, it's meaningless.

At the very bottom layer is semiconductor physics, where we have voltages, currents, electric fields in semiconductor materials. We build transistors to make controllable switches. That's the service to the next layer up, switches. We have over the years used many different types of things to make switches, CMOS FETs, bipolar transistors, relays, you can even use compressed air. But they all make switches.

The next layer uses the switches to control voltage levels, which we call high and low, and make logic. We've forgotten all about voltage by now. If there's a 3.3v rail, anything above 2.2v counts as 'high'. We connect the switches together to make logic gates, like NAND or an inverter.

The next layer uses these logic gates to make functions. Two NAND gates cross connected can make a memory cell. A bunch of those together can make a register. Many registers together with a tree of gates to make a decoder can make a memory. Another tree of gates can make an ALU. We've generally stopped thinking about individual highs and lows, and instead individual signals tend to be 'active' or 'inactive'. Groups of signals tend to have a collective meaning. Where we have several signals in parallel, let's say 8 of them, it's too much effort to keep thinking of them as '01100001', so we call it '0x31' (hexadecimal representation), and call it a 'word'.

The next layer is where we connect these functions together, and have an ALU, with a memory, and a bank of registers.

We have done experiments recently to grow these things genetically, throw a bunch of this stuff into an FPGA, see if it works, iterate, rinse and repeat. We sometimes get interesting results. But the 'design' is totally incomprehensible.

In order to get something we can understand and design, we simplify hugely, and define parts of the design. A single register will be a 'program counter', which will point into the current place in our 'program', a list of 'instructions' that we'll execute. This gets the name 'PC'. These are our concepts, injected into the situation to give meaning. In order to make the 'instruction' ADD B work, we need to have an adder section in the ALU, which gets enabled when the ADD instruction gets decoded. We choose a small pattern of highs and lows in the instruction word, let's say '1001', say this means 'add', design the decoder to only output an active signal when it's fed with '1001', and drive that to the ALU's adder. We pick another part of the instruction word, the address, in this case the B register, and give that an encoding, and use that to drive the input multiplexer for where the adder gets its source (I've chosen a single address instruction as common on 8080, which implies a single register, the accumulator or ACC as the other source address and the result destination, other machines also use zero address (stack based), two or three address (more flexible instructions).

We go through inventing more instructions with suitable encodings to make them work, naming the registers to make them easier to remember.

Now we have a programmable MCU. All we have to do is set the bits of the memory to represent the opcodes we want to execute. This is how very old computers were programmed. You had a bunch of switches on the front, and you'd have two people, one reading from a written list of instructions, 'set address 0x34B' to data '0x21', and the other one waggling the switches to set the memory. I had my first job in 1974, and I was one of those people, loading a 13 word program into a PDP-something-or-other that we still had running in the lab.

Obviously that's not scalable, so amongst the first programs written were program loaders, assemblers, editors, to automate that process.