obscuren
70f7a0be11
Use the state instead of the state object directly.
...
If a state gets reset and you still hold a pointer to the previous,
incorrect, state object you'll operate on the wrong object. Using the
state to set/get objects and attributes you won't have this problem
since the state will always have the correct object.
2014-10-16 13:38:21 +02:00
obscuren
311c6f8a3f
Fixed remote Arithmetic tests
2014-10-15 17:12:26 +02:00
obscuren
3d177be73e
Couple of minor issues fixed
...
* CALLVALUE pushed incorrect value to the stack
* Set execution model to closure
2014-10-15 00:40:41 +02:00
obscuren
b417766b36
Minor tweaks for poc7
2014-10-08 11:59:44 +02:00
obscuren
33a0dec8a1
Improved catching up and refactored
2014-09-15 15:42:12 +02:00
obscuren
d91357d00c
Added GetCode method
2014-09-08 00:50:04 +02:00
obscuren
42d43147ca
Changed log statements
2014-08-22 10:58:49 +02:00
obscuren
7d95e8624a
Added message to closure && added change addresses
2014-08-15 16:19:10 +02:00
obscuren
a760ce05b9
Updated chain for filtering
2014-08-11 16:23:38 +02:00
obscuren
03ce15df4c
ethstate.NewState => ethstate.New
2014-08-04 10:42:40 +02:00
obscuren
1f9894c084
Old code removed and renamed amount to balance
2014-07-30 00:31:15 +02:00
obscuren
32d125131f
Refactored to new state and vm
2014-07-24 12:04:15 +02:00
obscuren
1e8b54abfb
Refactored state, state object and vm
...
* The State and StateObject have been moved to their own package
* The VM is moved to it's own package
2014-07-22 11:54:48 +02:00
