deposit: refactor to forward deploys to L1

[marijanp]

Motivation

• Checking signatures and adding the deposit to the batch is not required to be done in the deposit endpoint.
• It should rather according to casper best-practices forward deploys to the L1.
• This deposit-deploy will be prepared in the kairos-cli and signed
• The signed deploy is sent to the L1 through kairos
• Once the L1 processes the deploy, an event will be triggered.
• The kairos server will then add the deposit to the batch.

TODOS

• 1. Don't break the other server tests, i.e. implement alternative deposit handler which can be used for property tests and only adds deposits to the batch
• 2. Integrate the deposit contract i.e. wait for it to be merged.
• 3. Implement the kairos-cli counterpart preparing the deposit deploy
• 4. Update the end-to-end-test

Successive PR

• use connect casper-event-toolkit with kairos-server, add deposit to batch see integrate casper event toolkit: add unprocessed deposits to batch on deploy #110

[jonas089]

"Checking signatures and adding the deposit to the batch is not required to be done in the deposit endpoint."

I'm not sure what is meant by this?

The Kairos server/ node will query the L1 for deposits and then roll them up in a batch together with Transactions and Withdrawals and produce a proof.

The proof is then submitted to another entry point of the demo smart contract that will verify it, extract the new root from the journal and update the contract state to store that new root.

[jonas089]

"It should rather according to casper best-practices forward deploys to the L1."

But native L1 deposits will still occur, so not every deposit will be forwarded from the L2 to the L1?

If you want to route Deposits through the L2 then yes this is the way to do it, but that's an additional means of depositing and not a replacement?

[marijanp]

@jonas089 the current implementation of the server suggests something different

kairos/kairos-server/src/routes/deposit.rs

Lines 24 to 52 in 27ef3fc

	pub async fn deposit_handler(
	_: DepositPath,
	state: State<Arc<BatchStateManager>>,
	Json(body): Json<PayloadBody>,
	) -> Result<(), AppErr> {
	tracing::info!("parsing transaction data");
	let signing_payload: SigningPayload =
	body.payload.as_slice().try_into().context("payload err")?;
	let deposit = match signing_payload.body {
	TransactionBody::Deposit(deposit) => deposit.try_into().context("decoding deposit")?,
	_ => {
	return Err(AppErr::set_status(
	anyhow!("invalid transaction type"),
	StatusCode::BAD_REQUEST,
	))
	}
	};
	let public_key = body.public_key;
	let nonce = signing_payload.nonce.try_into().context("decoding nonce")?;
	state
	.enqueue_transaction(Signed {
	public_key,
	nonce,
	transaction: Transaction::Deposit(deposit),
	})
	.await
	}

[jonas089]

@jonas089 the current implementation of the server suggests something different

kairos/kairos-server/src/routes/deposit.rs

Lines 24 to 52 in 27ef3fc

	pub async fn deposit_handler(
	_: DepositPath,
	state: State<Arc<BatchStateManager>>,
	Json(body): Json<PayloadBody>,
	) -> Result<(), AppErr> {
	tracing::info!("parsing transaction data");
	let signing_payload: SigningPayload =
	body.payload.as_slice().try_into().context("payload err")?;
	let deposit = match signing_payload.body {
	TransactionBody::Deposit(deposit) => deposit.try_into().context("decoding deposit")?,
	_ => {
	return Err(AppErr::set_status(
	anyhow!("invalid transaction type"),
	StatusCode::BAD_REQUEST,
	))
	}
	};
	let public_key = body.public_key;
	let nonce = signing_payload.nonce.try_into().context("decoding nonce")?;
	state
	.enqueue_transaction(Signed {
	public_key,
	nonce,
	transaction: Transaction::Deposit(deposit),
	})
	.await
	}

But if you forward a signed deploy to the L2 you might as well use the CLI to forward the deploy directly to the L1.

It will be recorded as an Event and then picked up by the L2.

Handling it differently introduces unwanted complexity.

For Withdrawals we will have to route the Deploy through the L2 but I'm not sure about deposits... Native L1 deposits and a good CLI should be good enough?

Another edit:
I think that for Withdrawals it's actually best for the L2 to verify a signature and then create and dispatch the deploy.

[marijanp]

@jonas089 If you ask me I would get rid of the deposit endpoint entirely. However the casper docs here and here suggest that we should forward through a backend.
Moreover @Avi-D-coder is interested in having an endpoint to be able to do low-setup property-tests.

[jonas089]

@jonas089 If you ask me I would get rid of the deposit endpoint entirely. However the casper docs suggests that we should forward through a backend.
Moreover @Avi-D-coder is interested in having an endpoint to be able to do low-setup property-tests.

Okay, shouldn't make a big difference, it'll work either way.

[github-actions]

File	Coverage
All files	59%	❌
kairos-tx/src/asn.rs	51%	❌
kairos-tx/src/error.rs	0%	❌
kairos-crypto/src/implementations/casper.rs	6%	❌
kairos-server/src/routes/deposit.rs	72%	✅
kairos-server/src/routes/deposit_mock.rs	88%	✅
kairos-server/src/routes/transfer.rs	90%	✅
kairos-server/tests/transactions.rs	90%	✅
demo-contract-tests/tests/test_fixture/mod.rs	97%	✅
demo-contract-tests/tests/test_fixture/wasm_helper.rs	66%	✅
kairos-server/src/config.rs	0%	❌
kairos-server/src/errors.rs	10%	❌
kairos-server/src/lib.rs	95%	✅
kairos-server/src/state.rs	90%	✅
kairos-server/src/utils.rs	22%	❌
kairos-test-utils/src/cctl.rs	90%	✅
kairos-server/src/state/transactions/batch_state.rs	36%	❌
kairos-server/src/state/transactions.rs	66%	✅
kairos-server/src/state/trie.rs	35%	❌
kairos-test-utils/src/cctl/parsers.rs	88%	✅

Minimum allowed coverage is 60%

Generated by 🐒 cobertura-action against 8a0736a

[Avi-D-coder]

lgtm

[jonas089]

lgtm

[koxu1996]

I would avoid compile-time environment variables, that breaks compilation outside of Nix. It's also annoying to see analyzer errors in IDE:

[marijanp]

So if you don't have this environment variable sourced in your development environment and run the code it will instead throw a runtime exception. Also sourcing environment variables is not accomplished with Nix but rather captured with Nix. My local development environment sources these environment variables for me automatically when I enter the kairos repository.