Implement `cartesi coprocessor publish`

[endersonmaia]

TBD

---

DRAFT

	- send the machine state to the solver
	- send car to ipfs (decide if we use ipfs public container or embed into cartesi/sdk)
	- check  :3034/ensure (SOLVER) if publish worked (healthcheck?)

[endersonmaia]

Should we also have a rollups publish to make the copy of the snapshot in a separate step, and have this deploy and publish steps aligned between coprocessor and rollups.

I think this way we give more visibility of what's happening, and also we can work towards an IPFS publishing the snapshot also for the rollups infrastructure.

[Nonnyjoe]

Yeahh.... @endersonmaia
I think splitting the current "rollups deploy" command into publish and deploy will actually create synergy between the coprocessor and the rollups development flow.

We can publish the machine snapshot in the publish step then deploy and register the necessary contracts like the application and authority in the deploy step.

[Nonnyjoe]

I'll Like to handle this next @endersonmaia

[tuler]

Why do you think a separate publish command is necessary? What was the benefit of a separate publish command in the case of coprocessor?

[Nonnyjoe]

Why do you think a separate publish command is necessary? What was the benefit of a separate publish command in the case of coprocessor?

In the case of coprocessor, the publish command does a couple of stuffs like:

• upload the carfiles generated from the build command to the operator and receive a CID
• Call the ensure route on the solver url attaching the previous CID, machine hash and size.
• Return a response to the users that the solver and operators are ready to start receiving requests.

With the rollups framework the last step is to deploy your application and this command deploys your solidity application so it's understandable, but with the coprocessor the publish command handles just making sure that the solver and operator has a copy of your application logic and is ready to begin processing request.

Users still need to deploy their application solidity contract which is where the coprocessor deploy command comes in.
That way users understand that after calling the publish command you still need to deploy your solidity application, it's easier that way than for users to call the deploy command to setup the solver and operator then still go back to deploy their solidity application.

We also considered publishing to the solver and deploying the solidity application in one go, but it becomes to complex in the sense that with rollups we have a unified solidity contract for everyone to use, so we are sure of the contract, constructor arguments and logic in general (eg it's not a factory contract or stuffs like that). But with the coprocessor framework each individuals contract is unique and might accept a different set of constructor arguments, plus the users can chose to use other methods like Remix to write and deploy their application so we thought it made more sense to separate the command into publish(machine logic) and deploy(solidity contract).

cc @tuler @endersonmaia @stskeeps

[tuler]

I don’t see that much difference between rollups and coprocessor. Rollups also allows applications to have custom smart contracts that interact with the InputBox (relays), like coprocessor does with custom smart contracts that interact with TaskIssuer.

Having another step in development flow (publish) requires more control of intermediate state. So I’m still unsure about the benefits.

[Nonnyjoe]

I don’t see that much difference between rollups and coprocessor. Rollups also allows applications to have custom smart contracts that interact with the InputBox (relays), like coprocessor does with custom smart contracts that interact with TaskIssuer.

Having another step in development flow (publish) requires more control of intermediate state. So I’m still unsure about the benefits.

The problem here now is the fact that combining the two command together will mean, every time you publish your application, you're automatically deploying the solidity contract, so there's no freedom to publish without deploying and this will definitely be a blocker to upgradeablility, for example a user would not be able to maintain assets in an already deployed contract and run some minor corrections by simply modifying his logic, republish the application then changing the machine hash in his contract to match the upgrade.

This will mean every single update would require a new publication, a new solidity contract and loss or transfer of any asset or data so far.

Separating these two commands will make a lot of process easier for the developer, and give room for people to play around with upgradeability. This is just one pressing issue I can think of at the moment, but I really do think that the benefits of splitting this outweighs combining the two commands.

[Nonnyjoe]

Hi @tuler
What's your final decision on the publish command, do we still go ahead to combine all 3 process?

[tuler]

do we still go ahead to combine all 3 process?

I think we can start with a deploy command that does everything (package, publish, deploy) and see how it goes.
Assuming the code is modularized into functions it's easy to create separate commands later if we decide to go in that direction.