The deployment of the 4337 contracts fail the first few times because of "insufficient funds".
| Error: insufficient funds for intrinsic transaction cost [ See: https://links.ethers.org/v5-errors-INSUFFICIENT_FUNDS ] (error={"name":"ProviderError","_stack":"ProviderError: HttpProviderError\n at processTicksAndRejections (node:internal/process/task_queues:96:5)
| at processTicksAndRejections (node:internal/process/task_queues:96:5)
If you keep running the command it works 🤔
Either Hardhat doing something bogus, or it's actually deploying one contract at a time, failing each time on the next thing?
The paymaster signer service doesn't run because:
ELIFECYCLE  Command failed.
Yeah right. Running manually works.
I'm suspecting the problem might be the way lib.run in libroll.py uses subprocess.PIPE to pipe the output, which is known to cause problems.
We should replace that with a system that supplies a stream abstraction (an object with a write and flush method IIRC) and spin up a thread that simply writes whatever comes in to a file. Unfortunate, but is is what it is.
Beyond all that, I need to better separate out setup from deployment from running. Ideally, just like the rest there would be separate commands for the setup (can't keep adding all extension to the global setup command), deployment, and running, and one "easy" command that does everything for you (what's implemented now).
As an optimization, we should skip the setup when it's already been done... but then also probably supply an equivalent to clean-build to remove builds that might be borked somehow.
Also:
Try using GOBIN instead of GOPATH so that we put stackup-bundler in ./bin and avoid installing things globally. This also means we only need to care about that variable when we go install and not each time we run like we do now.
We should add a configuration for the 4337 deployment name (currently "opstack") and default it to be the same name as the L2 deployment name.
Running into a few issues:
If you keep running the command it works 🤔
Either Hardhat doing something bogus, or it's actually deploying one contract at a time, failing each time on the next thing?
ELIFECYCLE  Command failed.
Yeah right. Running manually works.
I'm suspecting the problem might be the way
lib.run
inlibroll.py
usessubprocess.PIPE
to pipe the output, which is known to cause problems.We should replace that with a system that supplies a stream abstraction (an object with a
write
andflush
method IIRC) and spin up a thread that simply writes whatever comes in to a file. Unfortunate, but is is what it is.Beyond all that, I need to better separate out setup from deployment from running. Ideally, just like the rest there would be separate commands for the setup (can't keep adding all extension to the global setup command), deployment, and running, and one "easy" command that does everything for you (what's implemented now).
As an optimization, we should skip the setup when it's already been done... but then also probably supply an equivalent to
clean-build
to remove builds that might be borked somehow.Also:
Try using
GOBIN
instead ofGOPATH
so that we putstackup-bundler
in./bin
and avoid installing things globally. This also means we only need to care about that variable when wego install
and not each time we run like we do now.We should add a configuration for the 4337 deployment name (currently
"opstack"
) and default it to be the same name as the L2 deployment name.