feat(world): add Balance table and BalanceTransferSystem

[alvrs]

Fixes #1283
TODO

• fix WorldContextConsumer
• add test for WorldContextConsumer / WorldContextProvider with msgSender and msgValue
• add logic for updating root namespace balance when sending to world without calling a system
• add test for calling root systems with balance
• add test for calling non-root systems with balance
• add test for sending balance to world without calling a system
• add test for transferring balance between namespaces
• add test for transferring balance to address

[changeset-bot]

🦋 Changeset detected

Latest commit: 7ffde62

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 28 packages

Name	Type
@latticexyz/world	Major
@latticexyz/cli	Major
@latticexyz/dev-tools	Major
@latticexyz/store-sync	Major
@latticexyz/store-indexer	Major
@latticexyz/abi-ts	Major
@latticexyz/block-logs-stream	Major
@latticexyz/common	Major
@latticexyz/config	Major
create-mud	Major
@latticexyz/ecs-browser	Major
@latticexyz/gas-report	Major
@latticexyz/network	Major
@latticexyz/noise	Major
@latticexyz/phaserx	Major
@latticexyz/protocol-parser	Major
@latticexyz/react	Major
@latticexyz/recs	Major
@latticexyz/schema-type	Major
@latticexyz/services	Major
@latticexyz/solecs	Major
solhint-config-mud	Major
solhint-plugin-mud	Major
@latticexyz/std-client	Major
@latticexyz/std-contracts	Major
@latticexyz/store-cache	Major
@latticexyz/store	Major
@latticexyz/utils	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[frolic]

I don't know the "why" but I've seen folks prefer this approach over the above:

(bool success, ) = toAddress.call{value: amount}("");

[alvrs]

good catch! probably because of the 2300 gas limit of transfer (see https://twitter.com/obatirou/status/1697167795077698038 and https://medium.com/coinmonks/solidity-transfer-vs-send-vs-call-function-64c92cfc878a)

[frolic]

anything to be worried about here wrt reentry?

[ludns]

yes this smells like a re-entry attack

[alvrs]

Can you elaborate how a reentry attack would work here?

This is a utility that is used by call, callFrom and the World's fallback function, in each case just passing the msg.value to the SystemCall util. If the contract that's called in here would call one of these entry points again, it would still only pass that new call's msg.value to the function.

I think we need to update the balance table value before calling the system, because the system might want to transfer the balance somewhere else in this call.

[frolic]

I'm not an expert on this, reentry + managing balances/funds just makes me nervous and so wanted to make sure we've considered it.

I think the important thing is that the balance transfer happens before any code that can be called/overridden/injected by malicious actors? In this case, requireAccess is the only thing I can see but it doesn't make any external calls, so I think it's fine?

[alvrs]

Yes, requireAccess only checks an internal table.

Agree this is definitely a critical part of the system that we should be extra careful with and should also point this out as a focus area in the audit.

[frolic]

• do we need to protect against systems receiving value if not called through the world?
  • similarly but not related to this PR, should we prevent systems being called without the world entry point?
• does the world/root namespace have a way to withdraw all? if so, how should it update its accounting of balances? or will you have to specify the namespace to withdraw from?
• what if I just send value to the world? do we need to account for that or prevent it?

[ludns]

you can never prevent someone from sending eth to a contract, a contract can always self destruct and send value and not trigger your fallback

[alvrs]

• do we need to protect against systems receiving value if not called through the world?
  • similarly but not related to this PR, should we prevent systems being called without the world entry point?

Calling systems directly is not intended, but I don't think we should protect against it. As long as systems don't hold state it doesn't matter by who they're called since they will read/write on their caller by default. And there might be some advanced custom use cases where systems are limited to one World or do hold some internal state and the developers have some method for updating the internal state by calling them directly.

• does the world/root namespace have a way to withdraw all? if so, how should it update its accounting of balances? or will you have to specify the namespace to withdraw from?

Whoever has root access can theoretically withdraw everything by deploying a new root system to transfer all the world contract's balance out, but it's basically a rug pull and not intended (we can't prevent it though). In the ideal world namespaces can only manage their own balances, which is the case once root namespace access is burned.

• what if I just send value to the world? do we need to account for that or prevent it?

Right now the world can receive ETH without being attributed to any namespace via its receive function. We could update the root namespace's balance in that case?

[frolic]

Are there ways for funds to get into the world without triggering receive?

If so, do we want some way for the root namespace owner to withdraw address(world).balance - totalOfCurrentBalances as a safety/backstop?

[ludns]

Yes it is possible to not trigger receive (see my comment on selfdestruct)

…

On Tue, Sep 12, 2023 at 12:51 PM Kevin Ingersoll ***@***.***> wrote: ***@***.**** approved this pull request. Are there ways for funds to get into the world without triggering receive? If so, do we want some way for the root namespace owner to withdraw address(world).balance - totalOfCurrentBalances? — Reply to this email directly, view it on GitHub <#1425 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFBYUK4RYXLHZLD2QBF6KVDX2BEFRANCNFSM6AAAAAA4QIWAQQ> . You are receiving this because your review was requested.Message ID: ***@***.***>

[alvrs]

If so, do we want some way for the root namespace owner to withdraw address(world).balance - totalOfCurrentBalances as a safety/backstop?

I'd say because it requires real effort to send balance to the world without triggering receive we don't need to solve for this case (maintaining a totalOfCurrentBalances would increase the gas cost of every system call with value).

For anyone with root access to the World it's still possible to withdraw all balance from the World (with or without adjusting the Balances table) by registering a new root system.

[frolic]

For anyone with root access to the World it's still possible to withdraw all balance from the World (with or without adjusting the Balances table by registering a new root system.

How so?

[alvrs]

How so?

Root systems are delegatecalled and therefore can access the world state directly (including the World contract's balance)