How is the source code protected from being tamper

Question

class Block{
    constructor(timestamp, transactions, previousHash = ''){
        this.timestamp = timestamp;
        this.transactions = transactions;
        this.previousHash = previousHash;
        this.hash = this.calculateHash();
        this.nonce = 0;
    }

    calculateHash(){
        return SHA256(this.previousHash + JSON.stringify(this.transactions) 
        + this.timestamp + this.nonce).toString();
    }

    mineBlock(difficulty){
        while(this.hash.substring(0, difficulty) !== Array(difficulty + 
        1).join("0")){
            this.nonce++;
            this.hash = this.calculateHash();
        }

        console.log("Block mined: " + this.hash);
    }
}

In the above code, how is it promised that the underlying logic is not manipulated to one's advantage? I mean, to mine a block a miner has to invest immense computing power. If rather s/he is able to break the while loop above in the mineBlock() method, perhaps not much computing is necessary to mine a block and get it accepted (provided the source code could be manipulated in all the validator/miner (proof of work and stake respectively) machines). Thanks in advance.

Answer 1

perhaps not much computing is necessary to mine a block and get it accepted (provided the source code could be manipulated in all the validator/miner (proof of work and stake respectively) machines)

Since mining is a one-way algorithm, it is (currently) not possible to fake a solution without brute forcing until you get a solution. So, you cannot fake proof of work.

However, you mention that if the source code could be changed on all validators, they might accept a lower difficulty solution. This is true, but a few points on this:

1. It would be very difficult to modify the consensus code on all validators without anyone knowing. First, because the code is open source, and builds can be verified. Second, many are distributed around the world on different networks, running different versions and operating systems, so this is as much a concern for any software/computing devices.

2. In the case that this did happen, however, the consensus code could be patched and the network would recover by discarding all invalid blocks that were accepted after the breach.

If you are suggesting that code on all miners is modified:

1. Same problem as #1 above, except that not all miner software is open source, and there are many different mining software implementations.

2. All miners would then submit blocks at a lower difficulty, and the difficulty adjustment algorithm would lower the difficulty of the network because blocks are being solved slower. This would be more difficult to recover from, and would likely require a hard fork, since the consensus rules validated all of the blocks.

Answer 2

You shouldn't hide your client code because it kills the concent of blockchain and decentralized technology itself.

Technologies such as Bitcoin are unbreakable as long as 51% of computing power (in case of PoW consesus) comes from honest nodes.

In the moment that more than 51% of computing power is corrupted (malicious) then the ledger is not safe.

As many maximalist may suggest if your intent is to build your own blockchain probably you should re-use code that is already written and considered to be safe and add your features step by step.

Writing a DLT is not only about writing bug-less code (that cannot be used to corrupt all the nodes, as you stated in the question) but also efficient consensus mechanisms that cannot be exploited.

PoW stands for Proof of Work. DLT stands for Distribuited Ledger Technology (which includes Blockchain, Tangles etc.)

Just also to clarify some misconceptions which I've seen going out here.

Solidity is a deterministic language used to write smart contracts inside the blockchain (it is not the language used to code the blockchain itself but the code used for the softwares running inside the blockchain, example: Ethereum)

Taking Ethereum as example there are different implementations of it, geth (golang-ethereum) being the most active. As I told you if you want to create your own blockchain probably you should look to reuse code that is already proven to be solid.

Answering to: "new blockchain are prone to 51% attacks" (this plagues Proof of Work-consensus blockchains mainly): yes this is absolutely true, new born blockchains (or blockchains with low hash-rates) tend to be attacked frequently by renting hashpower (see Bitcoin Private case happened recently or Bitcoin gold). Unfortunately there's no way to prevent this from happening because it's just how Proof of Work consensus work, the only thing that can be done to contain it is that you wait more block confirmations before considering the assets coming from the transaction to be spendable.

Example (names are chosen randomly): I have an online store accepting BTW (coin) coming from Bitcoin Weak's blockchain which is often plagued by 51% attacks, what I do is that although customers transaction was inserted in block number (X) I wait up until block number (X + 100) before allowing him to spend those money in my platform.

Why do I do this? It's because 51% attacks aim to recreate two chains and insert the longer chain later on which deletes the shorter chain (the one where I created the transaction used to buy on your platform) so the longer confirmation blocks I await the more money I force the hacker to spend to keep the 51% hashrate attack going. If his double spend attack consists in spending 100$ but I force him to spend 101$ in electricity (or hashpower rent) then I discourage him to attack the chain and try to double spend in my platform.

Hope this clarified your doubts.