Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pointer for programs #536

Merged
merged 51 commits into from
Dec 13, 2023
Merged

Pointer for programs #536

merged 51 commits into from
Dec 13, 2023

Conversation

JesseAbram
Copy link
Member

@JesseAbram JesseAbram commented Nov 28, 2023

except for a few outlying questions this accomplishes the basics of #531

Done

  • Breaks up storage of program into program and a user can point to it
  • allows for removal of programs by person paying deposit

Future

  • allow for multiple pointers in registered when program linking happens
  • allow for config info when we can take inputted config changes (like a whitelist where we have the addresses as a config)
  • Allow governance controlled programs

Discussion

  • How do we handle removal if people are using (personally I like the idea of use for free but allow multiple ppl to pay and only remove the program if no one is paying for it)

Copy link

vercel bot commented Nov 28, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
entropy-core ✅ Ready (Inspect) Visit Preview 💬 Add feedback Dec 13, 2023 7:20pm

@ameba23
Copy link
Contributor

ameba23 commented Nov 30, 2023

I didn't make it to meet and discuss this yesterday so putting my thoughts here.

This looks like exactly what we want. If i've understood right, the new flow for registering with a new program would be to first submit the program, and then submit registration giving the hash pointer.

I'm not sure about 'removing a program' - i don't understand how this works but obviously we don't want to allow removing a program someone else is using.

In order to make this useful i guess we would need to maintain somewhere a list of program hashes and descriptions of what they do.

And for security we would probably want a way of proving the source code associated with a publicly available program. Being able to compile a program deterministically would solve this. I think we already talked about this at some point so i wont blabber on about it here.

Another issue (for later) would be that with, for example, access-control lists, there's currently no way of separating the boilerplate program code from the user-defined part (the list of allowed/blocked addresses).

@JesseAbram
Copy link
Member Author

I didn't make it to meet and discuss this yesterday so putting my thoughts here.

This looks like exactly what we want. If i've understood right, the new flow for registering with a new program would be to first submit the program, and then submit registration giving the hash pointer.

yes or even not have to submit the program

I'm not sure about 'removing a program' - i don't understand how this works but obviously we don't want to allow removing a program someone else is using.

ya we had a heated discussion about it, just gonna keep it as it and solve it in SD, a lot of ways to handle it, right now if someone is paying the deposit they should be able to pull it, also having chain controlled ones that don't require a deposit, but still ya kicking this to the retreat

In order to make this useful i guess we would need to maintain somewhere a list of program hashes and descriptions of what they do.

Ya we had the programs store concept which I like but that is for another day

And for security we would probably want a way of proving the source code associated with a publicly available program. Being able to compile a program deterministically would solve this. I think we already talked about this at some point so i wont blabber on about it here.

Had this convo @jakehemmerle made the program compilation deterministic which is fire ask him if you want more details

Another issue (for later) would be that with, for example, access-control lists, there's currently no way of separating the boilerplate program code from the user-defined part (the list of allowed/blocked addresses).

ya in the programs roadmap

JesseAbram and others added 2 commits December 12, 2023 09:57
Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>
Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>
pallets/programs/src/benchmarking.rs Show resolved Hide resolved
@@ -54,6 +54,7 @@ impl system::Config for Test {
parameter_types! {
pub const MaxBytecodeLength: u32 = 3;
pub const ProgramDepositPerByte: u32 = 5;
pub const MaxOwnedPrograms: u32 = 1;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to avoid the case where a dev six months down the line spends times trying to figure out why their test of multiple uploaded programs fails for some "mysterious reason"

pallets/relayer/src/lib.rs Outdated Show resolved Hide resolved
JesseAbram and others added 7 commits December 12, 2023 18:14
Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>
Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>
@JesseAbram JesseAbram requested a review from HCastano December 13, 2023 15:53
Copy link
Collaborator

@HCastano HCastano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for this!

CHANGELOG.md Outdated Show resolved Hide resolved
@@ -58,44 +56,22 @@ fn it_tests_get_validator_rotation() {
fn it_registers_a_user() {
new_test_ext().execute_with(|| {
let empty_program = vec![];
let program_hash = <Test as frame_system::Config>::Hashing::hash(&empty_program);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ya, this is nicer than before, thanks!

Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>
@JesseAbram JesseAbram merged commit fb247ba into master Dec 13, 2023
9 of 10 checks passed
@JesseAbram JesseAbram deleted the pointer-for-programs branch December 13, 2023 18:43
@HCastano HCastano added the Bump `spec_version` A change which affects the current runtime behaviour label Jan 23, 2024
HCastano added a commit that referenced this pull request Jan 25, 2024
HCastano added a commit that referenced this pull request Jan 25, 2024
* Add more notes around breaking changes in #536

* Be more explicit about breaking changes in `v0.0.10`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bump `spec_version` A change which affects the current runtime behaviour
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants