Hi raz from LayerZero.
So I want to first say we’ve never spoken to GFX Labs (despite reaching out) and although we now have time scheduled tomorrow (Monday), this analysis was written without a single question sent to us. I’ve gone through and done a line-by-line response to everything above but wanted to tl;dr some of the obvious mistakes in the analysis in case they get lost below in the broader post.
Firstly, GFX Labs missed the _getAppConfig() function which is the very first line of validateTransactionProof() with comments “Retrieve UA’s configuration using the _dstAddress from arguments.”
Taking a look at this function, you can clearly see that the first thing that it does is retrieve the User Application’s config and the default config.
Then it goes through each config item and if and only if the configurations are not set, the contract sets it to the default config item.
The crux of the GFX Labs argument seems to be centered around the perceived ability for the LayerZero ULN owner to be able to modify application parameters, however this is clearly not possible and enforceable in the immutable base layer of the code.
This seems clearly misleading as the two parties (oracle and relayer) are abstracted accounts with arbitrary implementation e.g. a fully decentralized network, not to mention the current proposal which I had assumed GFX Labs had reviewed extensively prior to this is for a new architecture with a number of major Uniswap delegates participating within the validation set.
The owner of the ULN contract cannot choose proof libraries on behalf of the user application. The owner can only add new proof libraries (i.e. append-only registry) of which the user application can select from.
The ULN can hold multiple validation libraries within itself for applications to choose from (ex. A zk-Validation Library could be added to the ULN V2 as a different method for verifying messages). This is an explicit design decision; LayerZero’s architecture supports the evolution of best cryptographic security practices. These libraries and the ULN itself are immutable and only by selection of the user application.
Most other bridges and messaging protocols offer blanket validation techniques and only upgradeable smart contracts. Many notable hacks have occurred due to a buggy upgrade forced upon applications built on top of a bridge’s infrastructure, including two identical instances from Wormhole resulting in a $10m bug bounty paid and then later reducing their bug bounty from $10m to only $2.5m.
To be clear, both of these issues are completely separate from the $325m hack Wormhole suffered.
We believe critical infrastructure should be immutable, open source, and always owned by user applications.
It is common practice to not open source or verify Oracle and Relayer smart contracts. These smart contracts are only responsible for on-chain quoting in gas. All validation logic resides immutably in the messaging library. In a competitive marketplace of Oracles and Relayers, unique pricing mechanisms are often the proprietary edge for providers. These smart contracts can only quote pricing and do not affect security in any way, therefore being verified is irrelevant to its purpose.
The Endpoint Contracts are for setting default configurations for developers to be able deploy and test easily. It is recommended that applications desiring more control over their security opt to set their own configuration settings. Default configuration cannot override user application configured settings; this is an explicit design decision and a feature of a true protocol.
The UltraLightNodeV2 settings are a combination of default configurations and one-time setters for adding new chains and proof libraries. The multisig owner cannot change any existing configurations set by the user or modify any existing validation libraries.
This statement is both entirely verifiably false and addressed in the opening part of the post.
I hope the line by line was helpful. I know we haven’t gotten to speak yet but looking forward to speaking to GFX Labs tomorrow and addressing any outstanding concerns and walking through the proposed security configuration in detail.