#336 Patract's treasury proposal for Ask! v0.3 (AssemblyScript Contract)
This is copy from https://kusama.polkassembly.io/post/766
Ask!'s goal is to provide a set of contract frameworks and compilation tools using AssemblyScript as the programming language. Contracts written through Ask! can run in the FRAME Pallet-Contracts , and eventually can call each other with contracts written by ink!. One month before, Ask! had completed the development of v0.2, and here was Development Report, External Review Form and Review Report for the previous version. After v0.3, we will release Ask! 1.0 as the first production version for massive test and usage for community developers and detailed docs.
Main features of v0.3
This proposal will complete the following functions on the basis of v0.2:
1. Add project management tool ask-cli
The positioning and function of ask-cli is similar to that of cargo contract, it mainly completes the following functions:
- Initialize the Ask! project. Provide
ask-cli initcommand to create a new contract project. It will mainly complete the following tasks:- Check the current latest version of
ask, and the dependencies of ask. - Create a project directory and initialize basic settings.
- Download/update all dependencies to the local directory.
- Check the current latest version of
- Encapsulate the compilation process of ask.
- Provide
ask-cli compilecommand to control the compilation process. Thecompilecommand will provide two modes ofdebugandrelease, and the default is to use thereleasemode to compile. among them:- In the
debugmode, debugging information will be generated in the.wasmfile, and the.wastandmetadata.jsonfiles will be generated at the same time, and the files expanded by Preprocessor will be saved to theextension/folder. - In
releasemode, the highest level of optimization options will be used to compile, and only.wasmandmetadata.jsonfiles will be generated.
- In the
- Provide
2. Performance optimization
2.1 Merging the functions of @storage into @contract, reducing the process of state variable definition.
In the implementation of v0.2 version, the @storage annotation was introduced, which is specifically used to mark that a certain class is used to save state variables, such as:
@storage
class StateVariable {
varA: i8;
varB: u8;
@ignore
varC: bool
// ...
}
@contract
class Contract {
sv: StateVariable;
// ...
@message
msgA(): void {
this.sv.varA = 8;
// ...
}
}
With this implementation method, the original purpose is to distinguish state variables and ordinary variables, so that when some parameters need to be passed across methods, ordinary variables can be used without additional storage burden, but this requirement is in v0.2 With the introduction of @ignore, there can be better implementations. At the same time, the use of @storage to distinguish variable types has obvious disadvantages:
- Introduced additional coding burden, each time you use it, you need to use the writing method of
this.sv.varA. - When the contract has an inheritance relationship, it is not convenient to arrange the storage location of the data in the subclass and the parent class.
Therefore, in v0.3, the functions of @storage and @contract will be merged. The contract in the above example can be written more directly as follows:
@contract
class Contract {
varA: i8;
varB: u8;
@ignore
varC: bool
// ...
@message
msgA(): void {
this.varA = 8;
// ...
}
}
2.2 Optimize the key generation logic used when storing state variables: Use continuous hash data instead of dynamic hash(string).
In the implementation of v0.2, the key used when storing state variables is obtained by calculating hash("_lang_ask.contract.varA"). This generation method is not convenient for more reasonable arrangement of storage locations, especially for collection types such as map and array.
In v0.3, for non-@ignore variables defined in the contract, storage locations will be generated in an orderly manner according to their declaration order (including variables of the parent class), as in the above example。The storage location of varA is 0x0000000000000000000000000000000000000000000000000000000000000001, the storage location of varB is 0x0000000000000000000000000000000000000000000000000000000000000002... and so on.
2.3 In the process of a message call, when the value of the state variable is changed multiple times, reduce the number of calls to seal_set_storage
In the implementation of v0.2, every time the value of the state variable is changed, the seal_set_storage method will be called in real time to save the result to the chain. The advantage of this implementation is that the value of the state variable will change in real time, which is very important when calling each other across contracts. But in most cases, it is not necessary to update state variables in real time, which will waste gas and consume IO operations.
In v0.3, the state variable will be updated in a lazy way, that is: in the process of a message call, the value of the state variable can be modified multiple times, but only after the message call is completed, will the final result be saved to the chain , So no matter how many times the state variable is modified, the seal_set_storage method will only be called once. At the same time, in order to meet the need to update state variables in real time when calling across contracts, a new annotation @immediately is introduced, which is annotated on state variables. If the state variable of @immediately is modified, its value will be real-time Update to the chain.
@contract
class Contract {
varA: i8;
@immediately
varB: u8;
// ...
@message
msgA(): void {
this.varA = 9; // won't update onchain value
// ...
this.varA = 18; // won't update onchain value
this.varB = 19; // update onchain value to 19 immediately
// ...
this.varB = 29; // update onchain value to 29 immediately
// ...
// update onchain value of this.varA to 18
}
}
2.4 Define the export format of Map and Array in metadata.json.
In v0.2, we provide the implementation of StorableMap and StorableArray, and in spread mode, they are saved as a doubly linked list, so that you can iteratively access all the data in StorableMap and StorableArry offline through the information provided in metadata.json. In order to achieve this goal, we will generate the necessary information for the StorableMap and StorableArray in the storage object of metadata.json. For StorableMap, its storage information is like:
{
"name": "someMap",
"layout": {
"struct": {
"fields": [
{// StorableMap info of entry node
"name": "entries",
"type": "spread", // storage mode, "spread" | "packed"
"layout": {
"key": "0x0000000000000000000000000000000000000000000000000000000000000002" // storage position
}
},
{
"name": "key",
"layout": {
"ty": 5 // data type of key
}
},
{
"name": "value",
"layout": {
"ty": 5 // data type of value
}
}
]
}
}
}
For StorableArray, like:
{
"name": "someArray",
"layout": {
"struct": {
"fields": [
{// StorableArray info of entry
"name": "entries",
"type": "spread", // storage mode, "spread" | "packed"
"layout": {
"key": "0x0000000000000000000000000000000000000000000000000000000000000002" // storage position
}
},
{
"name": "key",
"layout": {
"ty": 5 // data type of key
}
}
]
}
}
}
2.5 Use JSON instead of () annotations
In the implementation of v0.2, the parameter of the annotation is provided by (), such as@message(payable = true, selector = "0x1234"). In v0.3, it will be: @message({payable: true, selector: "0x1234"}) to improve the readability and maintainability of the code.
2.6 Enhance Event syntax, provide js library for parsing Event data
- Support @event inheritance
Event is essentially derived from the
_lang.Eventclass, in terms of syntax they should support inheritance. But in v0.2 does not support inheritance operations, in v0.3, we will support the Event class can be inherited. - Optimize the constructor and implementation method
In v0.2, because of the functional limitation of Proprecess, when we generate the Event construction method, we call the
emitmethod by default, and the code of the Event class after the Preprocessor is expanded:
class Transfer extends _lang.Event {
private from: AccountId;
private to: AccountId;
private value: u128;
constructor(from: AccountId, to : AccountId, value: u128) {
super();
this.from = from;
this.to = to;
this.value = value;
// code inserted by compiler
this.emit();
}
}
This implementation has the following problems:
- If the
returnmethod is called in the constructor method, thethis.emitmethod will not be called, resulting in the event not being sent. - The emit is defaultly used when constructing the Event, which is very unintuitive in coding.
For these reasons, we will optimize the implementation of Event to avoid the above problems by providing js library to parse Event data.
2.7 Enhanced annotation syntax and parameter checking
In the previous version, we have successively introduced multiple annotations, sub-annotations and annotation parameters, but before compilation, there was no good check during compilation, and no clear enough prompt information was provided when an error occurred. So in the v0.3, we will check all annotations and parameters in Preprocess, and provide friendly compilation information when errors occur.
2.8 Optimize the size of the generated wasm file
2.9 Upgrade the seal_xxx method in pallet-contract
Some seal_xxx methods in pallet-contract have been changed. In v0.3, the changed methods will be upgraded to the latest stable version.
3. Provide system parameter types in custom env
In the previous version, we used the FRAME provided in the Europa project by default, and defined the data types of the following system-level variables:
type Hash Array<u8>(32);
type AccountId Array<u8>(32);
type BlockNumber UInt32;
type Balance UInt128;
Although the default data type can meet most of the needs, in order to meet a small number of custom requirements, we will provide developers with the ability about custom Hash AccountId BlockNumber Balance data type in the v0.3 to adapt to different FRAME.
4. Unit Testing and Documentation
- Provide unit testing of Preprocess and framework.
- Provide tutorial documents for contract development.
- Provide framework API documentation.
Detailed timeline v0.3 (3 developers * 10 weeks)
- Week 1~2: ask-cli
- Complete the architecture design and implementation of
ask-cli. - Implement
init,compilefunctions.
- Week 3~6: Performance optimization work.
- Merge
@storageto@contract:- Expand the
@storagelogic in the implementation of contract to realize the read and write ability of state variables. - Optimize the key generation logic when storing state variables.
- A new method is added to the implementation of contract to generate storage logic for state variables, ensuring that
seal_set_storageis only called once. - Add
@immediatelyannotation, which acts on state variables, and the annotated variables will immediately callseal_set_storageto save.
- Expand the
- Enhance contract syntax.
- Standardize annotation usage, use JSON format instead of
()method - Enhance compile-time syntax checking, when encountering unsupported annotations and parameters, a compilation error will be thrown.
- Enhance
@eventclass, optimize implementation method and support event inheritance.
- Standardize annotation usage, use JSON format instead of
- Optimize the size of the generated wasm file.
- Define the export format of Map and Array in metadata.json, and provide js parsing library.
- Upgrade the
seal_xxxmethod to the latest stable version of pallet-contract.
- Week 7:
- Customize the
HashAccountIdBlockNumberBalancedata type in the env environment. - Update the usage of predefined environment variables in the framework.
- Week 8~10: Complete documentation and unit tests.
- Provide local test cases for Preprocess and framework.
- Provide ask contract development tutorial.
- Provide a tutorial on how to use ask-cli.
- Provide API documentation for each component in the framework.
Cost of v0.3 (30 developers * weeks)
- Operating activities: $6000 ( Rent and Devices: $200 per developer * week )
- Employee payments: $87000 ($2900 per developer * week)
- Total Cost: $93000 and monthly average: $203/KSM @ 28JUL
- Treasury Proposal: 458 KSM
How to verify v0.3 (github & docs & samples)
- Officially released npm library of ask and ask-cli.
- Reimplement the contract in examples with a new contract implementation method.
- Complete contract development tutorial.
- Complete API documentation.
Show More
Overall 41 % of users are feeling optimistic. The discussion surrounding the referendum on identity verification for council members has sparked valuable insights into the role of governance in the community. While opinions may vary on the necessity of such measures, the dialogue itself is a win for Kusama's development. Encouraging active participation and thoughtful consideration of governance issues is essential for the growth and evolution of our community. Let's continue to explore and define the unwritten rules that guide our decision-making processes, fostering a culture of collaboration and progress....
Overall 25 % of users are feeling neutral. The discussion revolves around the use of governance for decisions that should not be collectively decided. Some participants find maintaining a verified identity a hassle, while others believe identity verification is essential for validators. The proposal to enforce conformity is met with resistance, with one participant humorously questioning the need for identity verification. Ultimately, the sentiment is appreciated, but the majority lean towards rejecting the proposal.
Overall 33 % of users are feeling against it. The proposal to force an identity through governance is wrong. The identity fields associated with the wallet do not meet the requirements of a reasonably judged on-chain identity. Voters should not vote in favor unless they independently verify the identity fields. Corruption thrives on systems that expect people to be decent, but people are not, they are people. It's a bug, not a feature.
AI-generated from comments
The reason for my Nay vote on this one is because if I were under oath, I would not say that I "reasonably" know that the identity fields associated with the wallet are also owned and controlled by the signer of the wallet. Sure, there may be a mountain of testimonial evidence that the identity fields do indeed belong to Jam, but that does not meet the requirements of a reasonably judged on-chain identity.
It is my opinion that no one should vote Aye unless they send different messages to each of the identity fields for the wallet to sign, receive signatures from the wallet, then verify those signatures for themselves.
If Jam would like, he may use identity.requestJudgement on-chain to receive a judged identity. If voters have an issue with his identity as it stands they can always remove their vote or reach out to Jam.
Just to be clear, I have nothing against what this proposal is attempting to do - I too would prefer that all Councilmembers have judged identities. It's just that I cannot say in good faith that the set identity fields should receive a "reasonable" judgment.
Respectfully,
Adam
A fair enough response, thanks for taking the time to provide context.
I also voted against this, because I do not think that users should have their identity "forcibly" verified by others - they should request it themselves if they want it verified. I am sure that if he wanted to, JAM could have himself verified himself. I haven't seen any input from JAM about it, and in the absence of that, I have to vote against the Referendum.
Interesting points, forcing an identity through governance is indeed wrong
Voted Nay as "forcing an identity through governance is indeed wrong"
my position is always "don't use governance for things that shouldn't be collectively decided" :p but I got a chuckle out of the proposal
lol, I appreciate the sentiment, but I change my identity fields often enough that I find maintaining a verified identity a hassle - as other people have pointed out, it's not that hard to be verified if I want to 😅
Identity verification was designed for validators, to ensure people can trust they are nominating who they believe they are nominating, the authenticity of my onchain account can be verified in other ways - I usually ask people who want to send me stuff to get my address by going to the council page, for example :p but if that weren't a thing, I could ask folks to look up my address by index: yHF is incredibly easy to share and memorize - ("why Hard Fork?")
Just because we lack the swagger to make it in the grey circle club, doesn't mean we should force others to conform. Regretfully Nay.
I also voted Nay, because this should be at the discretion of the account owner, not of governance. Also, as mentioned above, we cannot verify the associated fields without the account owner completing the verification tests.
Council members should have verified identities IMO, but if stakeholders trust them enough to vote for them without a verified identity, that's their prerogative too.
What I would vote Aye for would be a remark urging JAM to verify their identity.
NAY'ing it too cause that's what registrars are there for.
If someone wants judgement => he should requestJudgement.
@@jam10o Thanks for receiving the referendum with a chuckle. It wasn't meant to be anything too serious and as I said in the OP there wasn't any consequence to matters of importance. It is good to see that there is some discussion, governance is imo more about these discussions than simply issuing a vote.
I expected comments in which voters disagreed and my original thought was to let these comments go without a detailed response of my own. To me, the outcome of the vote is inconsequential, the sentiment is more important.
There are however some responses that I disagree with as a matter of principle and I am compelled to respond. I wish to respond to three points:
- Should this be a voted on as a matter of governance despite having registrars?
- Is it reasonable to believe that the address belongs to JAM?
- Should we encourage council members and candidates to verify their identities?
What governance should or should not be used for.
I hold the view that governance should be used for ANYTHING that the code allows even if there are traditional ways of achieving the same result. If the intent is to limit this to matters of changing on-chain parameters or unbricking Parachains (which seems to be a bi-weekly thing) then please code the system as such.
If governance is limited in such a manner we should consider renaming the pallet to technical_updates or something like that.
Whether you agree with what is proposed is a different matter and for that you have the option to vote.
Should this be a voted on despite having registrars? Yes, we are doing it right now after all.
Matters relating to Identities
Original intent aside we should not narrow the usefulness of verified identities. If we apply the same core-principle as to why it was desired for validators, identities are equally or more important for council members.
JAM has established an identity himself. He has declared to the community via setIdentity that this address is his.
What he has not done is ask for someone to verify this. It is quite possible that due to his early status in the community and the small circles of communication that this was not required.
A registrar uses formal, efficient and deterministic mechanisms to establish that the address fields belong to the owner of the address. For his effort he charges a fee and for him to be given this authority the registrar must be established.
This does not dismiss the fact that ownership of said fields can be attained by other means and in an informal manner. If someone can prove that the facts or if they are so well demonstrated then is there the need to ask him to send an email, tweet or matrix response? Think principle not existing mechanism.
Imo, a mountain of testimonial evidence is sufficient to issue a reasonable judgement. As the judgement says it is reasonable to think that this is JAM.
Is it reasonable to believe that the address belongs to JAM? Yes, if this is not the case then we have been fooled for months upon years.
Council Matters
There's a few matter I can raise here but I'll keep the chat focused. I just want it stated that I believe JAM is a good council member, one of the best and I believe his personality is well suited to Kusama.
The idea that we have voting control over who is in the council is somewhat overstated. Yes, there is a voting process but the deciding votes lay with a few centralized authorities. With this reality we need to encourage council members to do certain things and imo verifying an identity is one of them.
Perhaps a better but more contentious governance vote would be to remove inactive council members but I leave the drama for another time :p
Should we encourage council members and candidates to verify their identities? Yes as a matter of principle.
@paradox I agree that the result of the proposal is of small importance and the discussion is much more interesting. So, I'll contribute to it a little more.
What governance should be able to do, in the sense what extrinsics can be issued as a result of a referendum, is a matter of a different discussion I believe. As it stands now that is any extrinsic, and so anyone should be able to propose anything and the community should vote on it. That's where the objective opinion of each voter comes into play on whether that's something governance should decide and if so, what the decision should be.
This is what is happening here and I don't think that anyone suggested you shouldn't have proposed it. If someone did, I'm 100% against that. But people are entitled to be against your proposal either because they feel governance should not decide on these matters or they believe the proposal is lacking in some other way (like the inability to verify JAM's identity).
Just because governance can call any extrinsic doesn't necessarily mean it should and each voter might make that decision based on principle, on the specific case under consideration, or a combination of the two.
So, should you be able to propose this? Since the current governance model allows it, definitely. Should people agree with your proposal? That's what we're voting on.
Now, you may very well be correct that there's no reasonable doubt this identity belongs to JAM. But personally I've never interacted with JAM, so I have no idea whether that's true or not. I could take your word for it, which personally I'd be willing to do, or try to verify it myself. But you're asking the whole community to do the same. And since we have registrars that are tasked to do precisely that, why should the community render a decision on this matter? This is one reason why I believe it's not the governance's role to enforce a verified on-chain identity.
The other is the word "enforce". I agree we should encourage council members to have an on-chain identity and I also agree that on-chain identity is not meant for validators alone. But encouraging and forcing-upon are two different things. JAM can decide for themselves if they want to verify their identity. If they decide against it for whatever reason, governance should not force a verification upon them. And even if it did, JAM could remove and re-add their identity, thus removing the verification, if they felt strongly about keeping it unverified.
The idea that we have voting control over who is in the council is somewhat overstated.
I disagree with this statement. As an individual, you have as much control as the amount of tokens you have and you're willing to vote with. Polkadot and Kusama (and PoS chains in general) are plutocratic because there's no way (yet) to associate only one account with an entity in order to give each account just one vote. By saying "we" you imply the smaller stakeholders, but large stakeholders have a right to participate too, and yes, they have a stronger voice than "we" do, for better or worse. My vote for a councillor might not make a difference, while a whale's might, but I can't deny them the right to their weighted vote whether I agree or not with their vote.
But as recent history has shown, the community can affect things when they want. So, collectively I wouldn't say that "we" can't affect voting results, which is something I find very encouraging and reassuring.
@michalis I think you're highly overestimating my conviction and desire to have the entire community vote in favour. It is not always about the outcome of the vote but the effect that it leaves, that's the true win/loss here.
The best I can hope for is awareness or consideration where it may not have existed previously. Even if passed, JAM can revoke the identity, the acceptance must ultimately come from him. Would he now reconsider given his public role? Would others follow in kind?
If I were to engage you with a response on some of the other items it would tangent towards the pitfalls of democracy as it is now. Some of these realities are best not said in the public.
@paradox I see where you're going with this. Yes, perhaps this could be a way to indicate the community's desire to have councillors have a verified identity. Personally, though, I feel it's a little "too much" for that purpose, which is why I stated that I'd be in favour of a remark, but not actually imposing a verification.
And yes, I understand that you have no intense conviction for this to pass, but since this is the proposed action we can use it as an example to discuss more fundamental things.
For example, I agree that governance should not be just for technical issues or unbricking parachains. It should be about anything someone feels merits a discussion and a vote. So, I'm really glad to see a proposal with a different "flavour" than what we usually vote on, even if I disagree with the proposed action. And IMO that's the real win here.
As to the pitfalls you mentioned, I remain optimistic. I don't think the model we have is perfect but I believe it has yet to fail us in any impactful way, it's quite advanced compared to other alternatives out there, and it's still a young WIP that can be improved in the future.
I had fun reading the details of the referendum, because it was so...unexpected! :)
Indeed, it proves that Democracy can be used to advocate for Community matters, beyond technicalities and emergencies.
I applaud this "Proof-of-Concept" use of governance mechanisms, and I hope that your initiative will encourage other community members (who are quietly mulling all sorts of ideas/suggestions/grievances about the state of Kusama) to put their KSM where their mouth is and file those referendum proposals on-chain! :)
Thank you for this!
Hey Paradox, I appreciate all the work you do in the community, and even appreciate this referendum even though I am voting against it. =) The conversation here is helping to define what governance is and the direction of Kusama, which is great.
That said, I disagree with this:
I hold the view that governance should be used for ANYTHING that the code allows even if there are traditional ways of achieving the same result.
I think that there is a difference what is technically allowed and what should be done. Even throwing away the Is-Ought distinction ( https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem, although that is also a fun rabbit hole to dive into), there are generally "unwritten" ("un-coded"?) laws of what governance does. These unwritten rules are valuable because they help bind a community together, but can be broken if necessary. Kusama, as a relatively young community, is still building up our unwritten rules.
It is possible to hard-fork Bitcoin to have a 69420 trillion cap, or change the coinbase reward, or remove halvings, whatever. But there would be a lot of social pressure not to do so, even though it's technically possible.
One of the reasons for the downfall of the Roman Republic (and its evolution into the Roman Empire) was the decline in these unwritten rules (https://en.wikipedia.org/wiki/Mos_maiorum). Emperors technically consulted the Senate, even though it became a much less powerful body over time. Emperors technically just had the powers of several Republic positions, such as Tribune of the Plebs and consul, just combined into one person. Nothing wrong with that! But it is very different from what anyone would have thought could/should have occurred a few centuries before.
Of course, sticking too closely to unwritten rules also creates stagnation. It's a hard question. But I think it's important that we also develop a sociocultural understanding of what governance should be used for, even if it can be used for other things. Culture has an impact on governance.
Again, I think the "proof of concept" here was valuable, and want to thank you for helping us to develop the unique Kusama culture. =)
Interesting proposal and comments. Just passing by to throw the random opinion that I share Paradox's view on the ANYTHING goes. If something can happen it will happen given it's rewarding enough, the issue is many people settle for very little, some people just want to watch the world burn🔥, for example I cross empty streets with a red light while smiling at the people that don't😂.
If anything the main reason I'm in this industry is the excitement to think that for the first time in history we have a tool that can help us organize our societies without much ambiguity, we should thrive to minimize/extinguish the need for those "unwritten" laws that are usually exploited by the more powerful. It's a bug not a feature! if we don't want something to happen write a test for it, watch it fail and add the code for it to pass. Corruption thrives on systems that expect people to be decent, but people are not, they are people. I don't blame them though they are just hackers abusing a poorly design system.
Discover similar proposals
