We probably agree that all public DLTs need an incentive to verify transactions, and now I mean all transactions (even smart contracts that don't convert cryptocurrencies). So is there or can there be a public DLT that has no native token of its own to provide this incentive? I might ask even better: is it theoretically possible to have a DLT for smart contracts (such as Ethereum) and pay for transaction verification not with gas, but with a token from a completely different DLT? Like Bitcoin?
The reason for this would be quite simple: a new token would not have to be introduced, which would have to build trust from the very beginning (as with the ICO). I realize that transaction verifiers will always have to have an incentive to authenticate.
A cryptonetwork without a token, say X, could do some above-standard over Bitcoin, but we wouldn't want to make an X-coin to serve as a reward for verifiers, because then the project of cryptonetwork X would have to be big enough for the exchanges to notice. would introduce the X-coin / Bitcoin exchange pair.
So we have a hypothetical DLT named X. Therefore, we introduce that some hypothetical transaction verifier on X be paid in Bitcoins.
Let's look at it specifically. I am "A". "A" sends a transaction to X's ledger to "B" in the form of a smart contract that Bitcoin does not understand. In order for a transaction to be written to the ledger, it must be verified. But the verifier does not want any X-coin, because he would have a problem with its exchangeability at the beginning of the operation. So what happens?
Let's make X an extension of Bitcoin. The very original idea was that X’s miner would be paid for in an already established token. This is a fundamentally different scenario than we see today, when new miners do not get too involved in a new project because they carry a relatively high risk. Suddenly they will knock so they can verify for the new X.
Because X has a protocol that Bitcoin does not understand, you need to have new authenticators (I thought so, but it's not true, read on). They will be motivated by paying for an already established cryptocurrency. This means that the new DLT network named X will benefit from the established trust in Bitcoin. Using cryptographic logic gates (such as those used in the construction of the Lightning Network), two DLTs can be combined (as we have seen, for example, in Atomic Exchanges).
A small number of verifiers for X, but a large one for Bitcoin, would not be a problem at all. I can imagine miners selling themselves to any DLT if they are paid out in Bitcoin. But I would still mind that I had to have two miners: a miner who would process the payout in Bitcoins to another miner on X. That sounds inefficient. But let's put that aside for now.
The introduction of new DLTs in the normal way is in principle similar to forking - a disproportionately unfavorable introduction of completely new DLTs. I understand the principle of the market, the tokens of only those DLTs that make sense will be retained, on the other hand, I do not think that this results in meaningless and continuous creation of more and more tokens.
The difference between X and forking or the classic introduction of the new DLT is abysmal: forking makes incompatible miners and shrinks the network. The introduction of a completely new DLT is again extremely risky. Therefore, here is a solution in the form of X. Recall that the reason for all this is the fact that Bitcoin cannot do some advanced operations because it does not have them logged. Because of this, the verifier does not know when to come into contact with an advanced transaction what to do and whether everyone else understands the same.
In practice, everything would be roughly done by the sender of the transaction paying the verifier X in Bitcoins, so the Bitcoin transaction will obviously contain some all-encompassing ID. A bitcoin transaction is completed only if the verifier for X publishes a new transaction in X's DLT, otherwise it could happen to verify it and get Bitcoins, but it will no longer appear on the blockchain (which is captured in the classic model, because I can not deny to a blockchain transaction and get a mining reward).
If we start to examine the added value of the verifier for X, we will simplify the whole thing. The X authenticator function can be performed by the X user himself and the transaction initiator
.
Central to this is evidence that the transaction ID in X appears on the Bitcoin blockchain. The initiator pays for this - he does not pay for the fact that he can pay, but he pays for it to solve the problem of complete disclosure or the problem of Byzantine generals, if you will. So, for example, I take a transaction for X and incorporate its ID into a Bitcoin transaction.
The consensus will then be that if the shading Bitcoin transaction is in the Bitcoin blockchain before any conflicting one, then it is right. Cryptonetwork X then does not have to have its own native token. The conflict within X would be resolved according to the protocol.
Cryptonetwork thus only serves as a platform for public encryption keys aliases. Bitcoin's protocol will solve most potential problems, because it's actually enough to follow the Bitcoin blockchain where we integrated our X. If someone has a faulty transaction, it will be accepted in Bitcoin, but X users will ignore it. Of course, splits can occur in this virtual blockchain too.
The beauty is that even if you are the only user of your protocol, it will not compromise the security of your transaction at all. Imagine having the entire production process interwoven with smart contracts, electronic authentication and private key control (even if it would be damn expensive). Naturally, machines in the production process will also be able to create transactions because they have their own wallet. Machine-to-machine communication with the benefits of DLT would be implemented so that your machines understand your protocol. Sometime in the future, Bitcoin would function as a gigantic platform, where you pay for the amount of information included in the transaction (which is already partly true now).
Transactions X would no longer operate with the currency. The only API would be to interpret the Bitcoin blockchain into the X protocol language. Bitcoin would have only two functions - to put something into a public distributed database and reward the one who did it. No other things besides the P2PKH script would theoretically be needed.
If the new X were to manage ownership of the assets, I would still be able to do without a native token. This is because the asset (similar to the example above) will be interpreted by the Bitcoin blockchain and can track its own history of owners entered in the form of an account pair private-public key alias address.
With X you can make a corporate DLT (more than one blockchain), a completely private DLT or a fully permissionless DLT. All superstructure complexity is recorded in protocol X. Protocol X must be robust.
Note that elementary objects (addresses) do not have to interact directly at all, as they interact virtually with each other.So in the end, we went from complexity to total simplicity. It is possible that I overlooked something completely fundamental and it is completely useless, but not at all. Or something like that has been working for a long time. Please let me know. Thank you.
