Someone publish a minimal 90 GAS contract:
c#
void Main(string operation)
{
if (Runtime.Trigger == 0x07) // ApplicationR
{
throw(new Exception());
}
}
Then by sending a minimal transaction of 0.0000001 GAS (malicious transaction) nodes syncing from zero will differ from synced nodes if NEP7 is deployed, effectively breaking the chain.
Implement versioning mechanism from protocol changes that change execution behavior, contracts and blocks should be stamped by consensus nodes which version of protocol and VM they have been processed with and changes should enforce semantic versioning as they come online, this way a node processing NEP7 would know to process the block that published the malicious transaction.
this issue was raised on Feb 27: https://github.com/neo-project/neo/pull/172#issuecomment-368940710
For this example, there is no difference between whether NEP-7 is deployed or not.
If NEP-7 is not deployed, then this function will never be executed. And if the nep-7 is deployed, then the function throws an exception, just like no execution.
So the results are no different.
The problem comes when you start with empty blockchain, the node send you the blocks one by one, and we execute all of them for made the changes, is possible to change the storages values if we change the logic, if we don't create a version, for prevent the change of the logic.
void Main(string pp, object[] pp2)
{
var v=Storage.Get("a");
Storage.Put("a",v+1);
}
start without NEP7 -> receive the TX -> Trigger: Application -> Storage value =1
start with NEP7 -> Receive the block (with the tx and process it) -> Trigger: Application -> Storage value 1 -> Trigger: ApplicationR -> Storage value= 2
So this two nodes have different values in his storages, and they have the same blocks
One thing that came to my mind is that Payable flag can be used to indicate NEP-7 compatibility, so older contracts won't have a different behavior as @shargon described.
Another option is to distribute the blockchain together with a informing json file: from block 0 to X, NEO<=2.7.4, from X+1 to Y, NEO <= 2.7.5, ... And this can be used in blockchain import tools.
Finally, a third option would be to use NEP-10 supportedStandards method to guarantee NEP-7 was supported when fast-forwarding the blockchain.
Most helpful comment
The problem comes when you start with empty blockchain, the node send you the blocks one by one, and we execute all of them for made the changes, is possible to change the storages values if we change the logic, if we don't create a version, for prevent the change of the logic.
Scenario (pseudocode):
Results
NodeA
start without NEP7 -> receive the TX -> Trigger: Application -> Storage value =1
NodeB (height=0)
start with NEP7 -> Receive the block (with the tx and process it) -> Trigger: Application -> Storage value 1 -> Trigger: ApplicationR -> Storage value= 2
So this two nodes have different values in his storages, and they have the same blocks