Implementing event sourcing on credit transaction system

Currently we have a system that handles crediting and debiting of credits.

It stores each action as a transaction event in the database, but all in all we still update a "credit_bank" table that represents the current balance of the user.

          Table "public.credit_bank"
     Column     |          Type          | Modifiers 
----------------+------------------------+-----------
 id             | bigint                 | not null
 user_id        | bigint                 | 
 currency       | character varying(255) | 
 amount         | numeric(40,10)         | not null


                 Table "public.transaction"
      Column      |            Type             | Modifiers 
------------------+-----------------------------+-----------
 id               | bigint                      | not null
 amount           | numeric(40,10)              | not null
 credit_bank_id   | bigint                      | 
 status           | character varying(255)      | not null
 transaction_date | timestamp without time zone | 
 type             | character varying(255)      | not null

Since we process lots of transactions at a time, we were forced to lock the credit table every time we update it to avoid stale issues.

Then I came across event sourcing. Is that pattern good to apply in this scenario?

I'm really new to this, so please let me know if I have something wrong.

In my understanding, if we use event sourcing, we would not need to store the state of the "credit_bank", instead use events to come up with the state, or use snapshots. But how would that ensure that the current balance is still sufficient.

Also, if we get the state by processing events everytime, would that be bad for performance?