Instead of dumping 1 or 2k EVM scripts into the blockchain, is it feasible to embed only a hash of the EVM script and use something like IPFS for storing the actual script data? As smart contracts grow, putting them all into the blockchain seems like it is not a scalable solution.
I know this would be a departure from the “everything is in the blockchain” history of Counterparty.
But is it time to start considering this?
I actually thought about this a lot before writing the P2SH encoding CIP, but we can’t have consensus about data outside of the blockchain without having a (complex) way of ‘someone’ deciding what is and isn’t available / valid.
There’s no guarantee that when a block is found all the hashes of contracts in that block are available to all nodes, there’s no consensus mechanism for a node to determine if the contract just isn’t there or if it just isn’t there for him.
It seems trivial to make it so that only a select few nodes receive the data of a contract matching a hash that is in the blockchain and easily mount a sybil attack against a node.
I’ve also considered a p2p network of our own, but similarly there’s no (simple) way to reach consensus on what has and hasn’t been broadcast.
and with a p2p network comes a host of new issues in the form of DoS attacks that we need to fight (that’s why IPFS would probably be a easier alternative).
I think eventually, someday, we’ll have to move to a merge mined sidechain or something like that with the Counterparty protocol, but that’s pretty far down the line.
Can’t we use the same embed-a-hash mechanism as we’re doing with BVAM?
anchor transaction for the contract contains the hash BVAM style which can be used to lookup the EVM script on ipfs.
Somebody does have to host it but it doesn’t have to be the originator of the contract and Tokenly is already creating a federated BVAM provider infrastructure to bootstrap this before we get to a P2P network that could be piggybacked by EVM for the same purpose.
no idea what BVAM stands for / is 
can you point me in the right direction?
The problem with anything outside the blockchain is that there’s no way to reach consensus on if it’s available or not without coming up with some alternative consensus mechanism afaik
You are right. I’ve been coming to the same conclusion in my own thinking about this.
Let’s, for the moment, assume that IPFS is reliable and resistant to DOS attacks. The biggest issue I see is this: There is no way to prove that a piece of content actually exists in IPFS. As a malicious actor, I could submit a contract hash to the Counterparty EVM and say “Hey Counterparty nodes, here is an IPFS hash for a contract - go run it.” But I never submitted anything to IPFS and that hash doesn’t exist. Counterparty nodes would be waiting to receive a contract that never exists.
Even worse is the situation where some of the nodes do see IPFS content and some don’t. When it comes time to execute a block, the nodes will be out of consensus.
Thought experiment: I wonder if an XCP bond would solve this. So, I submit an IPFS contract hash and pay a 25 XCP bond. The transaction is mined and my XCP is held. If the transaction is real and reachable, then I get my 25 XCP back. If it was a fake contract, then I lose my 25 XCP.
The problem is, again, how do all the nodes determine with consensus whether the IPFS contract hash was real? And what if some see the contract and some don’t at different times? That is why we would need a P2P network to come to consensus. But then there are sybil attacks to deal with, so you would need a proof of stake system, etc… UGH!
I can’t see a way around this either, Ruben. Can anyone else think of a solution we are missing here?
yea and the BVAM has the same issue for consensus critical information, though it’s a good solution to non consensus critical information (I guess ipfs could be used as BVAM provider)
BVAM is ok with this because it is non-consensus information. BVAM is metadata describing a token’s purpose and real-world ownership outside of the blockchain.
This will come off as very strange at first, but I have thought about using Multichain in coordination with Counterparty, acting as a network of sidechains for auxiliary purposes and facilitation via SCs to reward sidechain operators with XCP.
The goal is to not bloat the Bitcoin Blockchain, which many of us try to be mindful of as we move forward, and to not bloat the Counterparty protocol, not rely on consensus lacking p2p networks, not rely on 3rd party provider trust and not to add new complex components to the Counterparty stack.
Multichain is probably the most Bitcoin compatible platform available and with the new Streams Feature, it becomes even more viable and useful not only on its own but for integrations as well.
If interested, let’s chat and form a working group to discuss further the feasibility of this proposal.