From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Jeremy <jlrubin@mit•edu>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts
Date: Wed, 08 Dec 2021 00:32:37 +0000 [thread overview]
Message-ID: <4RdeDclGQpoDin2VLO5Ngmoghw03BZ_tvdO0vaIp_fNWWlKL9tHeIz1iQMpHxAww2pzjI4NXYtNFuND5Qkj7AmvLUajSp4AKxNg70VWr3Rw=@protonmail.com> (raw)
In-Reply-To: <CAD5xwhjSZtm6X9J0w6uVg_ZDO7FuS=OCQ_kncURAcW_DuXq9HQ@mail.gmail.com>
Good morning Jeremy,
>
> Here's the day 6 post: https://rubin.io/bitcoin/2021/12/03/advent-6/, the topic is why smart contracts (in extended form) may be a critical precursor to securing Bitcoin's future rather than something we should do after making the base layer more robust.
*This* particular post seems to contain more polemic than actual content.
This is the first post I read of the series, so maybe it is just a "breather" post between content posts?
In any case, given the subject line, it seems a waste not to discuss the actual "smart" in "smart" contract...
## Why would a "Smart" contract be "Smart"?
A "smart" contract is simply one that somehow self-enforces rather than requires a third party to enforce it.
It is "smart" because its execution is done automatically.
Consider the humble HTLC.
It is simply a contract which says:
* If B can provide the preimage for this hash H, it gets the money from A.
* If the time L arrives without B claiming this fund, A gets its money back.
Why would an HTLC self-enforce?
Why would a simple paper contract with the above wording, signed and notarized, be insufficient?
An HTLC self-enforces because given the Bitcoin network, it is not possible to violate and transfer the funds outside of the HTLC specification.
Whereas a paper contract can be mere ink on a page, if sufficient firepower is directed at the people (judges, lawyers, etc.) that would ensure its faithful execution.
You puny humans are notoriously squishy and easily destroyed.
But we must warn as well that the Bitcoin network is *also* run by people.
Thus, a "smart" contract is only "smart" to a degree, and that degree is dependent on how easily it is for the "justice system" that enforces the contract to be subverted.
After all, a "smart" contract is software, and software must run on some hardware in order to execute.
Thus, even existing paper contracts are "smart" to a degree, too.
It is simply that the hardware they run on top of --- a bunch of puny humans --- is far less reliable than cold silicon (so upgrade your compute substrate already, puny humans!).
Our hope with the Bitcoin experiment is that we might actually be able to make it much harder to subvert contracts running on the Bitcoin network.
It is that difficulty of subversion which determines the "smart"ness of a smart contract.
Bitcoin is effectively a massive RAID1 on several dozen thousands of redundant compute hardware, ensuring that the execution of every contract is faithful to the Bitcoin SCRIPT programming model.
This is why the reticence of Bitcoin node operators to change the programming model is a welcome feature of the network.
Any change to the programming model risks the introduction of bugs to the underlying virtual machine that the Bitcoin network presents to contract makers.
And without that strong reticence, we risk utterly demolishing the basis of the "smart"ness of "smart" contracts --- if a "smart" contract cannot reliably be executed, it cannot self-enforce, and if it cannot self-enforce, it is no longer particularly "smart".
## The N-of-N Rule
What is a "contract", anyway?
A "contract" is an agreement between two or more parties.
You do not make a contract to yourself, since (we assume) you are completely a single unit (in practice, humans are internally divided into smaller compute modules with slightly different incentives (note: I did not get this information by *personally* dissecting the brains of any humans), hence the "we assume").
Thus, a contract must by necessity require N participants.
This is of interest since in a reliability perspective, we often accept k-of-n.
For example, we might run a computation on three different pieces of hardware, and if only one diverges, we accept the result of the other two as true and the diverging hardware as faulty.
However, the above 2-of-3 example has a hidden assumption: that all three pieces of hardware are actually owned and operated by a single entity.
A contract has N participants, and is not governed by a single entity.
Thus, it cannot use k-of-n replication.
Contracts require N-of-N replication.
In Bitcoin terms, that is what we mean by "consensus" --- that all Bitcoin network participants can agree that some transfer is "valid".
Similarly, L2 layers, to be able to host properly "smart" contracts, require N-of-N agreement.
For example, a Lightning Network channel can properly host "smart" HTLCs, as the channel is controlled via 2-of-2 agreement.
Lesser L2 layers which support k-of-n thus have degraded "smartness", as a quorum of k participants can evict the n-k and deny the execution of the smart contract.
But with an N-of-N, *you* are a participant and your input is necessary for the execution of the smart contract, thus you can be *personally* assured that the smart contract *will* be executed faithfully.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-12-08 0:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-07 23:29 Jeremy
2021-12-08 0:32 ` ZmnSCPxj [this message]
2021-12-08 1:11 ` Jeremy
2021-12-08 23:23 ` ZmnSCPxj
2021-12-23 9:42 Prayank
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='4RdeDclGQpoDin2VLO5Ngmoghw03BZ_tvdO0vaIp_fNWWlKL9tHeIz1iQMpHxAww2pzjI4NXYtNFuND5Qkj7AmvLUajSp4AKxNg70VWr3Rw=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox