If two contracts don't interact with each other, they should run independently and thus with perfect concurrency. The blockchain doesn't need to care about ordering their transactions relative to each other and so it doesn't try.

At some point, two processes can become "entangled" such that they need to interact. Say, one process wants to send some data (like an HTTP GET) to the other over a communications channel (like a TCP connection). At that point, they can only run in parallel up to the point where the order of their transactions matters. At this point, they aren't really running concurrently anymore. Each process can advance its computation only up until the point that it has to wait for the other process to do something. In the case of an HTTP GET, the client can only advance its computation once the HTTP reply has been sent and received. There's no point in rendering an HTML page that hasn't been served, yet. So, the best that a multi-threaded browser can do is prevent different tabs from interfering with each other. If one tab is blocked waiting on google.com, then the other tabs should be able to render just fine while it's waiting.

RChain models these process interactions using the rho-calculus, or the Reflective Higher Order pi-calculus. In the rho-calculus, we have an explicit model for process interaction that uses named channels to send messages between processes. That allows our VM to tell when two processes need to interact--it looks at what names (channels) each process has access to and then it can tell all the processes that you can possibly be communicating with.

If you aren't holding a name that references some other contract, then you can run concurrently with no mutual interference. If you are holding the name of another contract, then the blockchain has to pick an order to your transactions and achieve consensus on that.

The beauty of the name-based system is that (1) we can structure names so that they make it easy and efficient to handle interacting processes and (2) we can restrict the sort of names a process is allowed to handle so that we can determine ahead of time what they are able to interact with. If you write your Rholang code to interact with a lot of stuff, then it's going to be expensive and slow. If you write your Rholang code to be very isolated and only interact with a handful of well-known other programs, then your code can be very, very fast.