Ability to create contract instance by bytecode and ACI

[davidyuk]

depends on: aeternity/aesophia_http#81

[marc0olo]

depends on: aeternity/aesophia_http#81

why does this depend on this? I don't understand

[marc0olo]

@davidyuk I even think it should be possible to create the contract instance without relying on bytecode at all by just providing the ACI. can we do that?

if I am writing a frontend that just wants to interact with the contract (knowing the ACI) I shouldn't rely on the sourcecode or bytecode

note

• in this case the init / deploy method should throw an error of course

question
how does the SDK behave right now if I have a contract instance initialized which includes sourcecode/bytecode and is already linked to a certain contract address. is it possible to execute init / deploy then? if so what happens? old contract id gets ditched and replaced by the contract id of the new contract deployment?

[davidyuk]

why does this depend on this? I don't understand

Actually, not strictly depends, but would be nice to have a confirmation of bytecode comparison approach

I even think it should be possible to create the contract instance without relying on bytecode at all by just providing the ACI. can we do that?

Should be yes, I'll check it

old contract id gets ditched and replaced by the contract id of the new contract deployment?

Yep, the same with compile method. Probably better to throw exception in these cases

[marc0olo]

Actually, not strictly depends, but would be nice to have a confirmation of bytecode comparison approach

yeah, I think that needs more brains to figure out the best approach for this. maybe we should open a separate discussion issue for that.

Should be yes, I'll check it

👍

Yep, the same with compile method. Probably better to throw exception in these cases

We should cover each use case respective. Not sure if throwing errors is the best approach. Currently I would prefer throwing an error.

What usecases do we have for the contract instance?

1. source code only (bytecode & ACI available after compile)
   • initialization of contract instance requires (implicit) compilation to obtain bytecode and ACI
   • deployment possible if contract_id not defined
   • deployment not possible if contract_id is present
2. bytecode & ACI
   • no need for communication with http compiler
   • deployment possible if contract_id not defined
   • deployment not possible if contract_id is present
3. ACI only
   • no need for communication with http compiler
   • don't allow deployments at all

do we have verification methods on the contract instance right now for validating the bytecode? if so we can only support this right now for usecase nr. 1 and we are limited to a specific compiler version the SDK is connected to, correct?

[davidyuk]

do we have verification methods on the contract instance right now for validating the bytecode?

yep, see validateByteCode option:

aepp-sdk-js/src/contract/aci/index.js

Lines 99 to 103 in f1e9c4f

	if (validateByteCode) {
	const onChanByteCode = (await this.getContractByteCode(contractAddress)).bytecode
	const isCorrespondingBytecode = await this.validateByteCodeAPI(onChanByteCode, instance.source, instance.options).catch(e => false)
	if (!isCorrespondingBytecode) throw new Error('Contract source do not correspond to the contract bytecode deployed on the chain')
	}

[marc0olo]

yep, see validateByteCode option:

this should only be possible if source code is provided of course. should we otherwise skip with warnings or throw an error? I mean who would seriously try to validate bytecode without knowing the corresponding sourcecode? doesn't make sense to me 😅