Vyper: Audit Ready

Created on 10 Oct 2017  路  12Comments  路  Source: vyperlang/vyper

For Vyper to be audited we need to:

  • [x] 1) Remove Serpent dependency (I'm working on this)
  • [x] 2) Refactor parser (I'm working on this)
  • [x] 2) Improve gas estimation, the goal is for it to be as accurate as possible, but to err on the side of over
  • [x] 3) Add more tests in general (especially for new functionality and edge cases)
  • [ ] 4) Add documentation for all functionality to make Viper easy to understand for auditors, contributors, and smart contract developers

Some low priority tasks are:

  • [x] 1) Change bytes <= N, to bytes[max: N] #714
  • [x] 2) Add support for in to be used to iterate through fixed literal lists:for i in [1, 3, 7, 9]:
    ~-3) Add support for @modifiable_by(...), to be used based off of #382~ moved to post-beta

When you start a task please:
1) Make a separate issue to facilitate discussion
2) Tag it here so we can keep track of what's done, being done, and needs to be done.
@jacqueswww @fubuloubu

Cute Animal Picture

image

Most helpful comment

@fubuloubu I created #714, which is basically the last item except for documentation on the Audit Ready list :)

All 12 comments

I like your choice of animal "I've bit off more than I can chew!" Lol

@DavidKnott @fubuloubu could we maybe review these items here for our next call. Would be great if we could see what's still outstanding (even if we add more to the list).

I think #529 might be something that we should consider for being "audit ready" because it facilitates ease of use and discovery for our little language

Name change is definitely a pre-requisite: #501

Change bytes <= N, to bytes[N]. We're using it like a fixed list!

@DavidKnott needs a pre beta tag, sort of by definition lol

@jacqueswww @DavidKnott I think we're nearing "audit ready"

Once all the "pre beta" issues are closed, we should take a halt on non-bug updates, bumpversion to "0.1.0-rc", and start working on coverage defunct analysis and then we should all do a review of the test cases. Once that settles, we get some security/formal verification people to look at it before we do a release to "0.1.0", and presto-change-o it's released!

@fubuloubu I ticked all the ones I know that are definitely done. Except for documentation (that has it's own issue) - I suggest we move all the uncomplete ones into post-beta issues? Thoughts ?

Basically creating an issue for:

Change bytes <= N, to bytes[max: N]
As
Add support for @modifiable_by(...), to be used based off of #382 already has it's own issue.

I think @modifiable_by(...) can definitely be moved to post-beta as it is can be added without problem in a feature release after v1.0. I would be very okay with that syntax even changing a bit.

bytes <= N:
I still don't like this syntax, it's very ugly and I wish it would change. I don't see a problem with bytes[N] where N is a literal, net-positive integer. the max/<= syntax always seemed cumbersome to me, exposing an underlying concern that is not directly of very much use, especially when (I believe) it still takes up N bytes, at least when computing gas usages.

People don't use it very much (right now), so I wonder if making this a pre-beta change would be advisible, before we get a larger flow of people into the language using it for who knows what.

@fubuloubu I created #714, which is basically the last item except for documentation on the Audit Ready list :)

Closing as we have another issue pre-beta for documentation :smile:

Was this page helpful?
0 / 5 - 0 ratings