In the description of view key generation, it is not clear to me what the following things are, exactly:

• The ppaccount_sig value.
• The ppaccount_cm value.
• The AccountSignature.GeneratePublicKey function.
• The AcountCommitment.Commit function.

It looks like Aleo Studio uses ~/Aleo Studio as working directory (on macOS), which is reasonable, but it may be nice to provide a way to customize that location. I couldn't find the option in the Preferences.

This https://developer.aleo.org/developer/programming_model/model#accessing-input-registers makes reference to registers, but I believe that it may be obsolete.

Overview

New Leo syntax just dropped🔥

Operators and syntax can be found in this PR ProvableHQ/leo#2394

• Add each operator to table https://developer.aleo.org/leo/operators#table-of-standard-operators
• Check that arguments and return type are correct

Currently the Aleo Instructions documentation points to the Aleo SDK - it should be refactored to point to the SnarkVM CLI https://developer.aleo.org/aleo/installation#2-build-source-code

Some suggestions on
https://developer.aleo.org/developer/language/imports

• Starting right at the top, it would be good to describe what sorts of entities can be imported. It appears that any top-level definition from a file can be imported, as long as the file is in a reachable location, either under the src directory or under the imports directory (wherever that is) according to a certain directory pattern.

• It would be good to be clear about what a "project" vs a "package" is throughout the docs, to be consistent in the nomenclature. It would be good to define here what a package is.

• The first section, Local: Import from a local file in the same package src/ directory by its file name. This sentence is hard to parse and should be reworded to be clearer. Maybe: Import from a local file in the src/ directory of the current package.

• Also in Local, I suggest making this initial example simpler by importing a single name, not multiple names. There is a later section for Import Multiple.

• 2nd section, Foreign: Import from a foreign package in the imports/ directory using its [package] name. Is the imports/ directory defined anywhere? There should be a link to where it is defined. It is not clear in this section whether there is a config file somewhere that defines where it is, or whether it is supposed to be a sibling of the src directory (but that would not be very "foreign").

• Combined 1st section and 2nd section. If we simplify the 1st section so it is only importing the circuit Bar, then that would be the exact same syntax as the 2nd section: import bar.Bar; What if both files src/bar.leo and imports/bar/src/lib.leo exist and both have a circuit Bar in them. Which Bar would be imported? What if Bar is only in one or only in the other, would Bar be found in both cases?

• In the 2nd section, there is a little pattern describing what a Foreign import looks like: import [package].[name]; However, the other sections don't have little patterns describing what they look like. Also, can Foreign imports be renamed with the as keyword? This pattern implies that there are no other syntaxes for foreign imports.

• 3rd section, Package Paths. The first example seems to conflict with the Foreign example. The Foreign example has a lib file name that is omitted from the import declaration's package path. But this example has no lib file. Is lib handled specially and omitted? If so, this fact should be mentioned.

• The first three sections nicely show the imported definitions in one file and then the importing main.leo file. The last three sections, Import Aliases, Import Multiple, and Import Star could benefit from similar examples.

When starting Aleo Studio, the notification shown in the attached screenshot comes up.

When I first say the '[Not Available]' starting message text, I instinctively thought there was some error (e.g. some plugin or tool not being found). The rest of the message is clear and reassuring, but I would suggest to avoid starting the notification with what looks like a "negative", i.e. '[Not Available]'. Perhaps that part could be simply deleted, leaving the rest of the message. Another option could be not to show any message at all if there are no updates available, and instead show a message if there are updates.

As these are currently not implemented, we should align the documentation to the implementation.

It seems best to do this after #177 is merged, because the changes are not disjoint.

The top-right corned of Aleo Studio shows a sign-up button (see attached screenshot), but it's not immediately clear what one signs up for. I believe it is for the Aleo package manager web site. I understand that this is probably described in the Aleo Studio documentation (which I plan to read at some point), but it may be still worth considering providing more information in the GUI.

Proposal to add the Docusaurus Google Analytics plugin for improved user interaction tracking. Tracking analytics data points with Google Analytics is useful for Aleo as it provides valuable insights into user behavior, engagement, and content effectiveness on the site, enabling us to optimize the dev experience.

Plugin Info: https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-google-analytics

Implementation steps:

1. Install with npm install @docusaurus/plugin-google-analytics
2. Add to docusaurus.config.js:

module.exports = {
  plugins: ['@docusaurus/plugin-google-analytics'],
  themeConfig: {
    googleAnalytics: {
      trackingID: 'ALEO_TRACKING_ID',
      anonymizeIP: true,
    },
  },
};

Dependabot can't resolve your Rust dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

    Updating crates.io index
error: failed to select a version for the requirement `snarkos-dpc = "^0.8.0"`
candidate versions found which didn't match: 1.1.4
location searched: /home/dependabot/dependabot-updater/tmp/snarkOS/dpc
required by package `aleo-accounts v0.1.0 (/home/dependabot/dependabot-updater/dependabot_tmp_dir/accounts)`

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

We will be restricting loop variables to u32 since type casting has been pushed to dp3

I briefly did some research here, and it looks like it's not trivial, but @moAlobaidi would you mind taking a look?

Ideally, I'd like to remove the functionality altogether. If we can't then we should probably fix it.

In pages like https://developer.aleo.org/advanced/posw/posw/, some latex code can be seen but not rendered, which is not easy to read. It will be useful if mathjax is loaded on the page.

Looks like changes don't apply to the website on PR merge. Maybe we could set up some CI to do it? Or any other alternative such as a webhook?

As an example of this behavior:

1. Merged PR: https://github.com/AleoHQ/welcome/pull/98/files
2. No information on this page: https://developer.aleo.org/developer/language/variables/

This is purely aesthetic, but the menu on macOS references 'aleo-studio' instead of 'Aleo Studio', as shown in the screenshot below.

Dependabot can't resolve your Rust dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

Updating crates.io index
error: failed to select a version for the requirement `snarkos-dpc = "^0.8.0"`
candidate versions found which didn't match: 1.1.4
location searched: /home/dependabot/dependabot-updater/tmp/snarkOS/dpc
required by package `aleo-accounts v0.1.0 (/home/dependabot/dependabot-updater/dependabot_tmp_dir/accounts)`

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

New syntax added by ProvableHQ/leo#2401

• document group::GEN with example https://github.com/AleoHQ/welcome/blob/master/documentation/leo/03_language.md#group-elements
• add group::GEN opcode https://github.com/AleoHQ/welcome/blob/master/documentation/leo/04_operators.md#table-of-standard-operators

Tracking issue for the following:

• Document call in aleo instructions documentation
• Document that mappings are stored on chain publicly in aleo instructions and Leo
• Document that mappings are in program inside program scope
• Document a finalize function must immediately follow a transition function
• Document that finalize function same name as transition function
• Update prism syntax highlighter for Leo - make public blue

A couple outdated things in the current docs that I noticed need some updating to support the current model (in no particular order):

• "gates" has been renamed to "microcredits" and is only allowed in credits.aleo records.
  • The example in the Programs seconds also need to be updated - https://github.com/AleoHQ/welcome/blob/0e7c1556a18f8400d4d09ba79237c1a0d7d0d6e7/documentation/concepts/01_programs.md?plain=1#L27
• Transactions
• Transitions now do not have proofs (as they are batched into the execution proof)
• Block headers and metadata now have additional fields
• New fee model is in place for finalize, deployments, etc.
• Concept of finalize needs to be added

New releases for Leo are found at https://github.com/AleoHQ/leo/releases
Documentation updates should be pushed to https://developer.aleo.org/leo/installation

The docs here may be confusing. Provide the following for correct usage using snarkos:

• snarkos developer scan --view-key "${VIEWKEY}" --endpoint "https://vm.aleo.org/api" --last 100
• snarkos developer scan --private-key "${PRIVATEKEY}" --endpoint "https://vm.aleo.org/api"
• snarkos developer scan --view-key "${VIEWKEY}" --endpoint "https://vm.aleo.org/api" --start 30000 --end 50636

Two problems with the doc about Leo.toml.
Problem 1:
The section "File Syntax", describing Leo.toml, mentions the section [package]
but when I do leo new hello-world my Leo.toml contains [project], not [package].
Problem 2:
The section "File Syntax" does not describe the [remote] section.

https://developer.aleo.org/testnet/getting_started/deploy_execute_demo/ we might want to remove the --fee 25000000 parameter in this page

Update documentation typo in Inline Functions in the Leo Language Guide

Task

Change:

The rules for functions (in the traditional sense) are as follows:

There are three variants of functions: transition, function, inline.
- transitions can only call functions and inlines.
- functions can only call inlines.
- inlines can only call inlines.
- Direct/indirect recursive calls are not allowed

To:

The rules for functions (in the traditional sense) are as follows:

There are three variants of functions: transition, helper, inline.
- transitions can only call functions and inlines
- helpers can only call inlines
- inlines can only call inlines
- direct/indirect recursive calls are not allowed

Aleo Instructions now supports output to a given type in core

hash functions https://github.com/AleoHQ/snarkVM/pull/1647
commit functions https://github.com/AleoHQ/snarkVM/pull/1656

Leo implementation ProvableHQ/leo#2415

Tasklist:

• Add hash functions to opcode table
• Add hash functions to language guide
• Add commit functions to opcode table
• Add commit functions to language guide
• update hash functions in opcode table to take any argument type

When viewing the Aleo Developer docs (Mining Process Section), there is a typo in the heading "Security & Miner Size" as shown in the attached photo:

It appears that the raw markdown file associated with that section has an escape character ('\') that isn't being recognized.

I observed this typo using both Mozilla Firefox 84.0.2 (64-bit) and Google Chrome Version 87.0.4280.141 (Official Build) (x86_64)

Hey guys!
I wrote several times in Discord, so now I'm here)
The site https://faucet.aleo.org/ has rendering issues on laptops with 1920x1080 resolution, making the search box invisible.
A lot of us are faced with it.

So users need to set up their Zoom to 90% in order to search the address.

The markdown check constantly fails checks because links are either not reachable or error out, so solved this, we currently disable the markdown checks for link(s).

We should come up with a better option such as a whitelist, etc.

Reference:

• https://github.com/gaurav-nelson/github-action-markdown-link-check

The page https://developer.aleo.org/concepts/accounts says that:

• A private key consists of 58 characters, but the example consists of 56 characters.
• A proving key consists of 58 characters, but the example consists of 57 characters.
• An account view key consists of 56 characters, but the example consists of 53 characters.

I'm not sure how to fix this, because I don't know enough of these formats yet to determined if the error is in the assertions or in the examples. That's why I'm opening an Issue instead of a PR.

When I visited the aleo.studio web site for the first time today, I noticed that, as shown in the attached screenshot, macOS was selected (presumably by the browser detecting that I’m on a Mac), but the description just below the download button referred to Linux. In fact, when I clicked the download button, I got a .deb file.

Clicking on Linux and then macOS solved the issue — the text under the download button changed to ‘macOS 10.13.0 and newer’, and I got a .pkg file (which I installed successfully).

When I re-visited the aleo.studio page a second time (after closing the browser window), the glitch was no longer present.

However, when I used a different browser to visit the aleo.studio page (Firefox instead of Safari), I saw the glitch again.

Perhaps the glitch disappears once there is some cookie or cache data. Please note that, if you have visited aleo.studio before, you probably won't see the glitch. If you want to try and reproduce the issue, please try a browser that you've never used to visit aleo.studio. Perhaps cleaning the cache/history may reveal the issue too.

https://github.com/AleoHQ/welcome/blob/34b6b79b1357e69eac2c5e05823a703d239073b4/documentation/developer/language/11_console.md?plain=1#L68

This is no longer true. Variable values are printed in the build stage now.

https://developer.aleo.org/aleo/concepts/blocks#timestamp
https://developer.aleo.org/autogen/testnet/public_endpoints/getblock#response

Is it seconds, milliseconds, microseconds or nanoseconds since epoch?

Overview

• Refactor Aleo Instructions https://github.com/AleoHQ/snarkVM/pull/1643

• Refactor Leo syntax ProvableHQ/leo#2413

Does Aleo have any public RPC endpoint?

• Add index of all endpoints https://developer.aleo.org/testnet/getting_started/overview
• Update latest snarkOS endpoints https://github.com/AleoHQ/snarkOS/blob/testnet3/node/rest/src/routes.rs

Create a page with network requirements at developer.aleo.org/testnet/getting_started to reflect the changes outlined here and also maintain going forward.

block.height is being implemented in Leo ProvableHQ/leo#2420

I suggest to improve the description of private key generation as follows, in order to have a precise definition of private key generation (amenable to formal specification):

• Add a link to RFC 7693 — the official definition of BLAKE.
• The official spelling is BLAKE2s, not Blake2s. (Maybe not a big deal.)
• The notation Blake2s(arg1,arg2) suggests keyed BLAKE2s, but my reading of the snarkVM code a while ago (this should be double-checked) indicates unkeyed BLAKE2s, with the two arguments suitably concatenated.
• I think it would be better to use a concatenation notation for the two parts of the input, instead of two arguments separated by commas.
• Clarify that the 0 and 1 passed as second arguments to calculate sk_sig and sk_prf are encoded as unsigned 16-bit integers, same as counter to calculate r_pk.
• I would expand u16 to unsigned 16-bit integer.
• The endianness of the two bytes that form these u16s should be clarified. My reading of the snarkVM code a while ago indicates little endian (this should be double-checked).
• There is a pending PR to clarify that the counter starts at 2 to calculate r_pk.

Run cargo run in accounts dir, we got errors.

Because project structure have changed a lot in 3 years.

The example at https://developer.aleo.org/developer/getting_started/syntax#syntax-to-circuits is

// The 'hello-world' main function.
function main(a: u32) -> u32 {
    return a
}

but when I run the latest version of Leo from GitHub I get

// The 'hello-world' main function.
function main(a: u32, b: u32) -> u32 {
    let c: u32 = a + b;
    return c
}

(which is indeed a nicer example to show).

All edit this page links are currently broken and give a 404

In https://developer.aleo.org/developer/getting_started/syntax#wiring-program-inputs
it mentions the .state file but does not describe its contents.

Is the .state file used for anything? When I do leo new hello-world, if I want to
change the input and output data types, I can do that in the .in file. At that point
the .state file is inconsistent with the .in file. However, I don't seem to see anything
go wrong due to this inconsistency. It is as if the .state file is ignored. However,
the fact that it is inconsistent is worrisome.

As per title

https://developer.aleo.org/developer/language/operators#arithmetic-operators

Documentation on division should describe the semantics on integers.
Is a/b well-defined if a is not a multiple of b?
Does it do floor, or ceiling, or round?
Does it adjust towards negative infinity or towards 0?

It would probably also be good to mention that division on field values
a/b should be well defined for any field values a and b except b = 0field.

Create a Changelog section above Aleo in the nav bar (see screenshot). We'll use this section to highlight changes and feature updates on an ongoing basis. The first addition to this changelog should be the fixes outlined in this project.