Resolved Netcode and Custom Physics

The main thing to worry about would be how you deal with "stateful" data. A basic physics engine would have rigidbody velocities as its stateful data, but a more complex physics engine might store a lot more stateful data than this in order to improve stability of physics stacks for example.

In netcode, when clients receive state from the server, they must rollback the state of the world to what the server said it was at the tick of the received data snapshot, and re-simulate ticks until the present is reached. So for a simple physics engine, only rigidbody velocities would need to be rolled back to the past state. However, with a more complex physics engine, you'd also have to sync & rollback all the extra stateful data as well, and depending on how much data you have here, the cost of doing this might be too heavy. If you don't rollback that stateful data, the client & server simulations will differ, and this will lead to jitter due to prediction errors.

So if the physics engine you're trying to port was not designed from the ground-up with netcode prediction in mind, there's a chance it simply cannot be a good fit for netcode prediction. I don't know enough about Box2D to comment on its netcode compatibility though

 

This is a big complex topic, but I would recommend reading about it in this multi-part series: https://www.gabrielgambetta.com/client-server-game-architecture.html

I think the term "rollback" isn't used here, but it generally means "reverting the state of the game to past"

 

This past state must generally be sent over network from server to clients, because the server might have reached a state that is a little bit different from clients. Or if clients join mid-game, the server must send the full state.

However, there are cases where the server could benefit from a history buffer. For example, when a client wants to shoot their weapon, they may tell the server "I tried shooting at tick X", and the server might use a collision world history to perform the shot raycast against the state of the collision world at tick X

 

I could be wrong, but I believe you would have to manually specify that your physics update must be part of the PredictedFixedStepSimulationSystemGroup, which comes with the NetCode package. This will call your updates the correct amount of times for prediction

When using Unity.Physics, the fixed update automatically gets moved there, but without Unity.Physics I'm not completely sure it does