Steps to reproduce:

• Run demo-dapp-pet-shop on MacOS Mojave
• Adopt some pets
• Lock the computer
• Unlock and try to adopt another pet (should hang)
• Reloading will show pet was adopted, however will still hang on subsequent adoption clicks

Error:

The dapp hangs on the following line:

https://github.com/OffchainLabs/arb-ethers-provider/blob/2182c185c38cb45a9771324998eab337c4777a4b/lib/index.js#L154

New interface will be created in https://github.com/OffchainLabs/arb-util/issues/1

on truffle migrate --reset --network arbitrum I get:

Traceback (most recent call last):
  File "/usr/local/bin/arbc-truffle-compile", line 4, in <module>
    __import__('pkg_resources').run_script('arbc-solidity==0.1.0', 'arbc-truffle-compile')
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 739, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1493, in run_script
    code = compile(source, script_filename, 'exec')
  File "/usr/local/lib/python3.5/dist-packages/arbc_solidity-0.1.0-py3.5.egg/EGG-INFO/scripts/arbc-truffle-compile", line 34
    f.write(f"{instr} {instr.path}")
                                  ^
SyntaxError: invalid syntax

full trackeback: http://paste.debian.net/1086338/

Much of the unit testing from arb-avm will have to be ported to this package.

Stack hashing should adhere to the specification at https://developer.offchainlabs.com/docs/AVM_Specification/#stacks. Stack implementation must include major optimization from arb-avm only greedily calculating the hash up to N items from the top. This allows for a still constant time to hash the machine, but removes the need to be constantly hashing as the top of the stack churns.

This depends on the implementation of value hashing in OffchainLabs/arb-avm-cpp#1.

As part of the goal of optimizing the Arbitrum virtual machine, we want to minimize and abstract the interface between this package and arb-avm. This requires auditing all uses of arb-avm, creating an abstract interface that the arb-avm Machine class implements and potentially moving other functionality in arb-avm into a separate arb-lib library.

Arbitrum uses an asynchronous messaging system for cross contract communication. This is general incompatible the the synchronous call system which standard Ethereum contracts use. This prevents full contract interoperability between Arbitrum contracts and Ethereum contracts.

Despite this, a weaker setup of asynchronous communication is possible. In the current version of Arbitrum, Ethereum contracts can send data to Arbitrum VMs which arrives after a delay with its sender properly authenticated. However the opposite is currently impossible and so there is no way to return data from Arbitrum VMs to Ethereum contracts.

External calls out of Arbitrum VMs show up in the system as messages. Currently messages that go to other VMs are delivered into their inboxes. Messages to other destinations (user addresses or Ethereum contracts) lead to currency being delivered into an EthBridge controlled wallet that can then be withdrawn from by its owner. This avoids the need to make calls directly into untrusted contracts. It would be fundamentally unsound to require that assertions involve making synchronous calls into untrusted contracts since they could be malicious.

There are number of solutions to this issue:

1. Have a set of whitelisted contracts that are honest which synchronous calls are made to automatically when an assertion is accepted.
2. Make message calls from a VM be optional and allow any validator independently make them on the VMs behalf after an assertion has been accepted.
3. Other VM specific solutions

Due to there being a wide array techniques to handle this issue, including the fact that there could be optimized per VM solutions, providing an abstract and pluggable interface to solve this issue would be great. We can then provide a large space of options for people to choose within.

This versatility can be accomplished through the use of the owner interface. An owner is a special contract linked to a VM and trusted by its validators. This contract has a number of management features that affect and are linked to the functionality of the VM.

I propose the addition of the following function to the owners interface which will be called whenever a message is sent from the VM.

function didSendMessage(
    bytes32 _destination,
    bytes21 _tokenType,
    uint256 _amount,
    bytes calldata _data
)

This interface would admit any of the discussed implementation options on a per VM basis.

An additional possible expansion of this interface would be to provide the option to cancel the actual transfer if the owner returns false.

function didSendMessage(
    bytes32 _destination,
    bytes21 _tokenType,
    uint256 _amount,
    bytes calldata _data
) returns (bool)

Introduced in https://github.com/OffchainLabs/arb-avm-cpp/pull/13

Each subscription creates a new thread that makes its own periodic calls to the server. It's better to have one thread that calls the server and gets all logs, then distributes them to each subscription as needed.

Images sizes were as low as 30MB (see OffchainLabs/arb-validator#11). PR OffchainLabs/arb-validator#14 balloons all validator image sizes to 80MB.

One way to keep both build caching and a slim static build is to split the process into 2 separate Dockerfiles (since internal Dockerfile stages cannot be exported easily). The first would either produce 80MB including the build executables and the build cache. The second would just use the executables.

Steps to re-produce:

1. Start a demo dapp i.e. arb-deploy --dev-mode --keep-alive contract.ao 3
2. docker ps
3. docker kill pet-shop_arb-ethbridge_1

Expected error (excerpt):

arb-validator1_1             | panic: runtime error: invalid memory address or nil pointer dereference
arb-validator1_1             | [signal SIGSEGV: segmentation violation code=0x1 addr=0x1c0 pc=0x56279644cbba]
arb-validator1_1             | 
arb-validator1_1             | goroutine 94 [running]:
arb-validator1_1             | github.com/offchainlabs/arb-validator/validator.(*Validator).Run.func1(0xc0000c0000, 0xc0000af5c0, 0x5627968d39a0, 0xc0000200b0)
arb-validator1_1             | 	/home/user/validator/validator.go:188 +0x26a
arb-validator1_1             | created by github.com/offchainlabs/arb-validator/validator.(*Validator).Run
arb-validator1_1             | 	/home/user/validator/validator.go:176 +0x5f
arb-validator-coordinator_1  | panic: dial tcp: lookup arb-ethbridge on 127.0.0.11:53: no such host
arb-validator-coordinator_1  | 
arb-validator-coordinator_1  | goroutine 64 [running]:
arb-validator-coordinator_1  | github.com/offchainlabs/arb-validator/ethvalidator.(*EthValidator).StartListening.func1(0xc0000ae028, 0xc0000200b0, 0xc000532f60, 0xc0000ae038)
arb-validator-coordinator_1  | 	/home/user/ethvalidator/validator.go:185 +0x51d
arb-validator-coordinator_1  | created by github.com/offchainlabs/arb-validator/ethvalidator.(*EthValidator).StartListening
arb-validator-coordinator_1  | 	/home/user/ethvalidator/validator.go:162 +0x156

VM execution deviates from correct behavior when calling the SEND and NBSEND opcodes. Bug was detected running the go AVM against the cpp AVM.

The combination of tracking inbox messages as well as message sends should allow the vm to track its current wallet balance. This is used when deciding whether a send is successful or not. There's no current specification of these semantics (independently of this issue we should write up that spec), but this is implemented currently in the BalanceTracker class in arb-avm.

This depends on OffchainLabs/arbitrum#46.

Currently we support tokens in the EthBridge and in the AVM, but we don't have compiler support for this functionality. We need to introduce a way for solidity developers to do this.

The current leading proposal is to introduce a magic Arbitrum contract address that token related calls are sent to. This will involve defining an API for that special Arbitrum contract as well as modifying the call implementation to special case calls to that address.

This dapp tries to connect to: animalso.com and googleapis.com

https://github.com/OffchainLabs/demo-dapp-pet-shop/blob/e82c3b748680f6aea53da52b889c4d7de831b7e0/dist/index.html#L42

https://github.com/OffchainLabs/demo-dapp-pet-shop/blob/e82c3b748680f6aea53da52b889c4d7de831b7e0/dist/index.html#L54

By removing these external sources, local development could occur offline

An RPC to FindLogs, with a large value of toHeight (say, math.MaxInt32) will crash the validator. This is because accesses to the slice of past assertions are not bounds-checked.

Instructions specific in https://developer.offchainlabs.com/docs/AVM_Specification/#instructions. This issue is to track that each opcode has been implemented and tested.

Implement hashing as described in https://developer.offchainlabs.com/docs/AVM_Specification/#hashing-values

Currently Arbitrum clients have to trusts the correctness of transaction results that it gets from the validator. That means that at the moment it's only safe for validators to be clients of the VMs. However by getting and checking a proof that the transaction result came from a log value in an accepted assertion, the client can AnyTrust transactions results.

Implementation of this functionality depends on OffchainLabs/arb-validator#1

Running arbc-truffle-compile produces different outputs on different runs .

Machine hashing should adhere to the specification at https://developer.offchainlabs.com/docs/AVM_Specification/#hashing-a-vm-state.

Depends on OffchainLabs/arb-avm-cpp#1 and OffchainLabs/arbitrum#44

The EVM has a number of different types of inter contract calls. Currently we support CALL and STATICCALL, but we should also support CALLCODE and DELEGATECALL.

Why is tokenNums created using balance.TokenIndex for unanimous assertions and precondition.BeforeBalance.TokenIndex for disputable assertions?

balance.TokenIndex

https://github.com/OffchainLabs/arb-validator/blob/f7ca75895afc0095ba006f3c0846ec95916c58ea/ethbridge/ethbridge.go#L568

https://github.com/OffchainLabs/arb-validator/blob/f7ca75895afc0095ba006f3c0846ec95916c58ea/ethbridge/ethbridge.go#L608

https://github.com/OffchainLabs/arb-validator/blob/f7ca75895afc0095ba006f3c0846ec95916c58ea/ethbridge/ethbridge.go#L650

precondition.BeforeBalance.TokenIndex

https://github.com/OffchainLabs/arb-validator/blob/f7ca75895afc0095ba006f3c0846ec95916c58ea/ethbridge/ethbridge.go#L723

https://github.com/OffchainLabs/arb-validator/blob/f7ca75895afc0095ba006f3c0846ec95916c58ea/ethbridge/ethbridge.go#L689

Once https://github.com/OffchainLabs/arb-util/issues/1 has been completed, arb-validator should be refactored to make use of the new incremental machine execution interface

New interface will be created in https://github.com/OffchainLabs/arb-util/issues/1

The ErrorCodePointHash and HaltCodePointHash are defined here: https://github.com/OffchainLabs/arb-avm/blob/c5d41a9e4ba12ae1f0645f9e37f75862399bf166/value/codePoint.go#L185-L186

and should be set to 1 and 0 respectively, to match the informal AVM specification. Also, need to check arb-ethbridge to make sure change is reflected everywhere. For example, in the OneStepProof haltInstructionState is set to 1, whereas the spec states '0': https://github.com/OffchainLabs/arb-ethbridge/blob/9ffd1e424e3d29663911fa855d0bfae9748940f0/contracts/OneStepProof.sol#L720

The Arbitrum compiler should not be run if there is a solidity compiler error.

Steps to reproduce:

git clone --depth=1 https://github.com/OffchainLabs/demo-dapp-pet-shop ps && cd ps
yarn
truffle migrate --reset --all --network arbitrum
echo INVALID >> contracts/Adoption.sol
truffle migrate --reset --all --network arbitrum

Observed error:

$ truffle migrate --reset --all --network arbitrum

Compiling your contracts...
===========================
Error: Error: CompileError: ParsedContract.sol:36:2: ParserError: Expected pragma, import directive or contract/interface/library definition.
}INVALID
 ^-----^

Compilation failed. See above.
    at Object.compile (~/.npm-global/lib/node_modules/truffle/build/webpack:/packages/truffle-workflow-compile/index.js:103:1)
Truffle v5.0.22 (core: 5.0.22)
Node v10.16.0
arbc-truffle-compile compiled.json contract.ao
Adoption 784030224795475933405737832577560929931042096197
Migrations 536549294809709735284832398280003200128834709884
6902

Expected behavior:

arbc-truffle-compile should not run if the truffle compilation fails

Note: the very first time an invalid migrate is run (or whenever the build/ folder does not exist) then the behavior is correct because arbc-truffle-compile is not run:

Compiling your contracts...
===========================
Error: Error: CompileError: ParsedContract.sol:36:2: ParserError: Expected pragma, import directive or contract/interface/library definition.
}INVALID
 ^-----^

Compilation failed. See above.
    at Object.compile (~/.npm-global/lib/node_modules/truffle/build/webpack:/packages/truffle-workflow-compile/index.js:103:1)
Truffle v5.0.22 (core: 5.0.22)
Node v10.16.0
Error: ENOENT: no such file or directory, scandir 'build/contracts'
    at Object.readdirSync (fs.js:790:3)
    at process.on (~/ps/node_modules/arb-truffle-provider/lib/index.js:36:20)
    at process.emit (events.js:203:15)
    at process.emit (~/.npm-global/lib/node_modules/truffle/build/webpack:/~/source-map-support/source-map-support.js:465:1)

When the VM is halted, it can never execute further instructions. When clients make calls to such a VM, the validators should respond with some reasonable error, so clients know the VM is halted.

Something is wrong with the way return values are handled, causing an unmarshaling error.

Currently we have to pin our version of ganache used for testing in the arb-bridge-eth Dockerfiles to version 6.5.0 rather than allowing it to upgrade due to trufflesuite/ganache#467. If this bug is resolved we will be able to upgrade to the latest version of ganache-core and ganache-cli.

All events produced by a transaction are interpreted as coming from the called contract rather than the contract that actually produced them.

EVM code files have a suffix at the end that contains metadata that will usually not be valid code. arbc-truffle-compile detects this (because it starts with 0xa165 or 0xa265, depending on solc version) and removes it before trying to translate an EVM code file.

This detection sometimes fails, leading to arbc-truffle-compile reporting invalid instructions at the end of the EVM code.

This seems to be happening because the 0xa165 or 0xa265 sentinel value is inside the immediate argument of an instructions, while arbc-truffle-compile only looks at the opcodes when scanning for the sentinel.

This is weird because in a valid EVM file the sentinel shouldn't be inside an immediate argument--that would make the EVM file, minus metadata, invalid as EVM code., which shouldn't happen.

Steps to reproduce:

1. Run arb-deploy --dev-mode contract.ao 3
2. Verify that the node_modules/arb-*-provider folders are symlinks
3. Run yarn add web3 or some package

Expected outcome:

Inspect that the arb-truffle-provider in node_modules is now a directory not a symlink

Temporary fix

Remove the compose folder and re-run arb-deploy in dev-mode or run:

rm -rf node_modules/arb-truffle-provider && ln -sf ../compose/arb-truffle-provider node_modules/arb-truffle-provider
rm -rf node_modules/arb-ethers-provider && ln -sf ../compose/arb-ethers-provider node_modules/arb-ethers-provider
rm -rf node_modules/arb-web3-provider && ln -sf ../compose/arb-web3-provider node_modules/arb-web3-provider

Having arb-deploy check that these are linked every time would work. Using yarn link is avoided because modifying the global link table in ~/.config/yarn/link could break other locally linked projects.

Steps to reproduce warning message:

1. rm -rf yarn.lock
2. yarn

Expected output:

warning ganache-core > web3 > web3-bzz > swarm-js > [email protected]: ⚠️ WARNING ⚠️ tar.gz module has been deprecated and your application is vulnerable. Please use tar module instead: https://npmjs.com/tar

Steps to reproduce in dev-mode:

git clone htttps://github.com/OffchainLabs/demo-dapp-pet-shop pet-shop
cd pet-shop
arb-deploy --dev-mode contract.ao 3

Expected error:

arb-validator-coordinator_1  | Finished waiting for arb-ethbridge:7545...
arb-validator-coordinator_1  | cp: omitting directory 'contract.ao'
arb-validator-coordinator_1  | incorrect version of .ao file
arb-validator-coordinator_1  | expected version 1 found version 0
arb-validator-coordinator_1  | 2019/08/01 14:57:30 open private_key.txt: no such file or directory
pet-shop_arb-validator-coordinator_1 exited with code 1

Secondary error:

Trying to fix this by creating a contract.ao by running:

truffle migrate --reset --network arbitrum

Will then lead to the secondary error:

...
arbc-truffle-compile compiled.json contract.ao
...
Traceback (most recent call last):
  File "/usr/local/bin/arbc-truffle-compile", line 7, in <module>
    exec(compile(f.read(), __file__, 'exec'))
  File ".../arbc-solidity/bin/arbc-truffle-compile", line 33, in <module>
    with open(args.output_file, "wb") as f:
IsADirectoryError: [Errno 21] Is a directory: './contract.ao'

This is because arb-deploy attempts to mount contract.ao as a volume. Because it does not exist, an empty directory is created named contract.ao. This is then a problem for arbc-truffle-compile.

Proposed solution

Check that contract.ao is a valid file before using it in arb-deploy

The Arbitrum validator should be able to produce and provide proofs of the values that have been logged by an assertion to validator clients that can be proved against the aggregate log commitment in all assertions. This will allow the clients to reduce trusting those values to trusting the assertion that they occurred in.

Trying to build a dapp that links in libraries leads to a failure in the arbc compiler. arb-truffle-provider needs to capture the EVM code after linking, rather than before.

Currently docker-compose build --parallel does not work because there is a build time dependency of arb-validator on arb-ethbridge. This dependency is because of information needed only at runtime. The files include:

ethbridge_addresses.json
validator_private_keys.txt
validator_addresses.txt

The build time dependency should be broken to allow parallel builds. The validators need ethbridge_addresses.json for the EthBridge contract addresses running on Ganache. This could be resolved at runtime by either:

• Mounting a volume with the addresses
• Or arb-ethbridge serving ethbridge_addresses.json to the validators at runtime

Currently validators also receive the list of private keys and public keys during the build phase. By passing the development mnemonic directly to validators, they can generate just their own private key and address.

The VM should implement the inbox functionality along with the inbox opcode as in https://developer.offchainlabs.com/docs/AVM_Specification/#inbox-and-messages.