It remains an open question how to provide censorship resistance in StarkNet. There are at least three lines of attack:
- secondary transaction channel - one way it could work is to have L1 inbox contract that allows L1 users submit L2 transactions as call data. No rollup state update is possible if there are transactions pending in the inbox. Right now it is problematic due to the way StarkNet handles invalid transactions: invalid transactions are unprovable which makes them indistinguishable from censored ones.
-
applicative escape hatch - similar scheme to the above but implemented on the application level: there is an application inbox on L1. L2 contract will freeze if there are pending transactions in L1 inbox. L2 contract will know when to freeze because it gets keep alive messages from L1. Keepalive messages will stop comming if there are unhanded transactions in the L1 inbox.
There are two problems with this approach:- increases ecosystem complexity as applications are stoppable in this approach and extra logic is necessary to accomodate this edge case. Imagine contract like DAI to be stoppable. All uniswaps of the L2 would need to work around it(or ignore it, which means ignoring censorship problem)
- this solution works as long not freezing the application is in the interest of the operator which might not always be the case. Imagine law enforcement agency requesting operator to freeze the application. All it has to do is to censor a single transaction.
- decentralization - having more than single operator should solve the censorship problem, theoreticaly anyone should be able to run the sequencer and include transactions. This should be futher reasearched as it depends on particular decentralization solution. It is also not clear how practical it will be to become an operator as it might require considerable resources.