Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: LayerZero uses fucking Google Cloud for Oracles by default now #216

Open
sambacha opened this issue Sep 17, 2023 · 2 comments
Open
Assignees
Labels
bug Something isn't working ℹ️ Discussion Informative Issue used for pre-planning / gathering requirements / etc
Milestone

Comments

@sambacha
Copy link
Contributor

LayerZero Oracle updates present a fixed centralization risk with questionable benefit, if any at all.

** Google Cloud Oracle (default as of 9/19/23) **
Google Cloud (GCP) provides a Google Cloud Oracle to secure messaging in the LayerZero Protocol.
The Google Cloud Oracle is the default Oracle for all dApps built using the LayerZero protocol.
Enterprises and developers of all sizes can now rely on the combination of an established entity (GCP) and a leading Web3 company (LayerZero) to address their interoperability challenges.
That said, each Oracle provides unique costs and benefits. UAs are encouraged to select the best Oracle that suits their needs.

{@see https://layerzero.gitbook.io/docs/ecosystem/oracle/default-oracle-updates}

Also, after reading more of their documentation we find:

Instant Finality Guarantee (IFG)
Reverting in UA is cumbersome and expensive. It is more efficient to design your UA with IFG such that if a transaction was accepted at source, the transaction will be accepted at the remote. For example, Stargate has a credit management system (Delta Algorithm) to guarantee that if a swap was accepted at source, the destination must have enough asset to complete the swap, hence the IFG.

What the fuck is this shit? No, this does not provide any sense of finality what so ever.

TLDR: LayerZero may be a worst version of Protocol Labs, truly dark times.

@sambacha sambacha added bug Something isn't working ℹ️ Discussion Informative Issue used for pre-planning / gathering requirements / etc labels Sep 17, 2023
@sambacha sambacha added this to the v1.0 RC milestone Sep 17, 2023
@sambacha
Copy link
Contributor Author

In fact, we must implement a custom UA configuration if we wish to enforce finality (as opposed to the retarded nonsense about IFG above

UA Custom Configuration

User Application contracts may set their own configuration for block confirmation, send version, relayer, oracle, etc.

When a UA wishes to configure their own block confirmations both the outboundBlockConfirmations of the source and the inboundBlockConfirmations of the destination must be configured and match.

We want to enforce block confirmations, this issue has been detailed in previous reports.

It also seems that, for whatever reason, they chose to arbitrarily enforce the same blockConfirmations inbound and outbound. Who is writing this documentation?

@sandybradley
Copy link
Contributor

UA config can be updated by admin when contract is deployed:

// generic config for LayerZero user Application
function setConfig(uint16 _version, uint16 _chainId, uint256 _configType, bytes calldata _config) external override onlyAdmin {
lzEndpoint.setConfig(_version, _chainId, _configType, _config);
}
function setSendVersion(uint16 _version) external override onlyAdmin {
lzEndpoint.setSendVersion(_version);
}
function setReceiveVersion(uint16 _version) external override onlyAdmin {
lzEndpoint.setReceiveVersion(_version);
}
function forceResumeReceive(uint16 _srcChainId, bytes calldata _srcAddress) external override onlyAdmin {
lzEndpoint.forceResumeReceive(_srcChainId, _srcAddress);
}

Steps for locking UA Configuration

Options for oracle are:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working ℹ️ Discussion Informative Issue used for pre-planning / gathering requirements / etc
Projects
None yet
Development

No branches or pull requests

4 participants