Daniyar Itegulov
Daniyar Itegulov
> Oh great, didn't know. First of all, is all errors handled like above? Secondly, I think the wording is just fine to me, but to make sure it is...
@volovyks By `"type": "error"` I just meant this is not `"type": "ok"`. For the record, our current deployments return errors like this: ``` {"type":"err","msg":"failed to verify oidc token: InvalidToken"} ```...
Good catch. Seems like we try to rollback even if transaction simply failed validation. Likely rollback logic just needs to be closer to where we actually send tx to batch...
Proposal: on estimation we run transaction with max possible gas once and if it fails we print summary, traces etc and exit early. Otherwise continue with the current flow.
Moving some thoughts from https://github.com/matter-labs/era-test-node/issues/364 to here. Indeed, `era-test-node` uses a placeholder block hash computation function that produces different results from `zksync-era`. My assumption was that this is perhaps not...
Most of the work needs to be done from core side but realistically has to be driven from our side as there is zero demand for having storage-agnostic metadata calculator...
@popzxc what do you think regarding that last question? Implementing this would be easy on a surface level but honestly I am not sure in the general usefulness of this...
Right, I guess in a non-single tx mode this is dependent on us following proper block sealing criteria from core that, among other things, will take this "fake" gas limit...