giseldo/neodataset huggingface dataset:
Node logs: shortens request status size in various events

```
Jan  6 14:33:10.900 - validator.block: block BLkhtA81uak1SxxCDCVMXEnXCKsJcFLajVT84ZjrFKbxAaJUL4E validated
Jan  6 14:33:10.900 - validator.block:   Request pushed on 2023-01-06T13:33:10.853-00:00, treated in 153us, completed in 45.531ms
```

In various places, we print the request status of some Requests to workers. It is a way to know how much time an operation took (like block validation).
However, it is hardly understandable by the user. 

- The `Request pushed` part gives no information to people with no knowledge of worker interface. 
- It is the same for the push time, on which Hour information is by the way not consistent with the log time
- `treated` is the time elapsed between the request submission to a worker and the beginning of its _treatment_. It doesn't seem to be of any help to someone that is not looking to debug a particular worker implementation 

### Proposed solution

Simplify the printing of the status in various places. Prevalidator and Block validator probably don't need the full printing and we could reduce the display to the `completed` information. In such a situation, the above display would become

```
Jan  6 14:33:10.900 - validator.block: block BLkhtA81uak1SxxCDCVMXEnXCKsJcFLajVT84ZjrFKbxAaJUL4E validated (45.531ms)
```

Story points: 3.0
Node logs: remove block properties (timestamp and fitness)

```
Jan  6 14:33:10.920 - validator.chain: Update current head to BLkhtA81uak1SxxCDCVMXEnXCKsJcFLajVT84ZjrFKbxAaJUL4E
Jan  6 14:33:10.920 - validator.chain:   (level 462824, timestamp 2023-01-06T13:33:10-00:00, fitness
Jan  6 14:33:10.920 - validator.chain:   02::00070fe8::::ffffffff::00000000), same branch
```

In some events advertizing new blocks, some properties are seen as obscure, and can even be found from elsewhere, like the `fitness` or the `timestamp`. Also they are probably not greppable, not especially useful for a developper. (Could the fitness be replaced by priority instead ?)

- timestamp
  - _Regarding the Update current head to message, I think it worth keeping the timestamp. Indeed, it is easy to know if your node is "up to date" while looking at it (if last block timestamp is very recent). The level requires a third party to get the "is my node synced" information._
  - we could replace by `4ms ago` which is shorter than `timestamp 2023-01-06T13:33:10-00:00
  - we keep only one unit (year month s ms )
  - is there a case where the timestamp is very different from the log date ?
  - don't display timestamp if close to current date ?

- fitness: ensure if useful or not (feedback: + Albin Romain), fitness can be found with the block hash.

Story points: 1.0
Continue "Translate the churny pytests `test_contract.py`"

Estimated translation time: 50 hours

Continuation of #3633 

 - [x] `TestManager` (@arvidnl !7056)
 - [x] `TestScriptHashMultiple` (~@linoscope !6840~, @arvidnl !7039)
 - [x] `TestContracts` (@rdavison !6625)
 - [x] `TestContractTypeChecking` (@rdavison !6503)
 - [x] `TestChainId` (@rdavison !6436)
 - [x] `TestExecutionOrdering` (@linoscope https://gitlab.com/tezos/tezos/-/merge_requests/7053/)
 - [x] `TestNonRegression` (@xf6 !6616) 
 - [x] `TestView` (@xf6 !6314)
 - [x] `TestTypecheck` (@lykimquyen  !6381)
 - [x] `TestBigMapToSelf` (@lykimquyen  !6325)
 - [x] `TestNormalize` (@linoscope !6394)
 - [x] `TestGasBound` (@lykimquyen !6684) 
 - [x] `TestScriptHashOrigination` (@lykimquyen !6627)
 - [x] `TestComparables` (@lykimquyen !6614)
 - [x] `TestBadAnnotation` (@lykimquyen !6642) 
 - [x] `TestOrderInTopLevelDoesNotMatter` (@linoscope !6604)
 - [x] `TestMiniScenarios`(@lykimquyen !6711) 
     - [x] `TestMiniScenarios` splits the test case entrypoints (@lykimquyen !6785) 
 - [x] `TestScriptHashRegression` (@arvidnl !6636)

Story points: 50.0
Start "Translate the churny pytests `test_contract.py`"

 estimated translation time: 48 hours (before split with #3942)

 - [x] `TestTypecheckingErrors` (@jaiyalas !6536, 1hr)
 - [x] `TestTZIP4View` (@lykimquyen  !6326) 
 - [x] `TestSelfAddressTransfer` (@lykimquyen !6437) 
 - [x] `TestBadIndentation` (@jaiyalas !6324)
 - [x] `TestOriginateContractFromContract` (@linoscope: https://gitlab.com/tezos/tezos/-/merge_requests/6382)
 - [x] `TestCreateRemoveTickets` (@linoscope !6105)
 - [x] `TestSendTicketsInBigMap` (@linoscope !6105)

Story points: 48.0
Translate the flaky pytests `test_tenderbake*.py`

estimated translation time: 14 hours

 - [x] test_tenderbake_bakers_restart.py (~~!6320~~ !6523)
 - [x] test_tenderbake_incremental_start.py (~~!6320~~ !6523)
 - [x] test_tenderbake_long_dynamic_bake.py (!6300)
 - [x] test_tenderbake_manual_bake.py (https://gitlab.com/tezos/tezos/-/merge_requests/6345/)
 - [x] test_tenderbake.py (!5245)

Story points: 14.0
EVM on WASM: Add TX kernel functionality to EVM kernel

The EVM kernel must be able to handle deposits, transactions and withdrawals just like the TX kernel. Add a new transaction type, `EVMtransaction`, that encapsulates an EVM contract call. The contents of this transaction is not so important for this ticket, only that it is there and that is used to dispatch to a `handle_evm_call` function.

Integrating with the TX kernel got complicated. The actual implementation of transaction _handling_ (as compared to the rest of the TX kernel structure) has been moved to issue: https://gitlab.com/tezos/tezos/-/issues/3698

This ticket is about porting the structure of the TX kernel to the EVM kernel including data types and splitting and/or amending those data types where needed for EVM transaction handling. Transaction verification of TX kernel transactions is complicated by interleaved EVM transactions and moved to the issue linked above.

Story points: 3.0
EVM on WASM: Run time for large/long transaction on EVM

Goal: find number of WASM instructions needed to run the largest EVM transaction.

Things to figure out and do in this issue:
- [x] How large is the "the largest" EVM transaction. Can we find this by looking at Ethereum history?
- [x] How much gas was spent on said transaction?
- [x] Write a contract that burns this amount of gas doing whatever.
- [x] How many WASM ticks are needed to run that transaction with the EVM interpreter we integrate with `kernel_next`?

Beware:
- Running the contract is only part of the transaction. After the transaction succeeds, the result needs to be written to permanent storage.
- Price (in WASM ticks and EVM gas) of storage interaction.

Story points: 3.0
EVM on WASM: common trait for encapsulating EVM interpreter

Encapsulate SputnikVM and Geth in each their struct. Each struct should implement one common trait/interface that allows for
- calling contracts
- providing precompiles
- interfacing with storage and transactions.
- intercepting `LOGx` instruction execution so that logs are not just part of the transaction, but also written to kernel log.

Story points: 1.0
EVM on WASM: Integrate with Geth

Goal is to integrate with an EVM interpreter so we can check and see if it is useful for our purpose. This issue is about checking geth.

Requirements:
- supports most recent version of EVM instruction set (if it doesn't, then something is very wrong); and,
- supports _precompiles_ in a way where we can define additional precompiles ourselves (not just the standard nine precompiles); and,
- doesn't require features from Rust `std` that we don't already use.
- capture execution of `LOGx` instructions.

Tests:
- some test contracts that return successfully
- some test contracts that fail - toplevel `REVERT` or using the standard invalid instruction.

Story points: 5.0
EVM on WASM: Integrate with SputnikVM

Goal is to integrate with an EVM interpreter so we can check and see if it is useful for our purpose. This issue is about using SputnikVM.

Requirements:
- supports most recent version of EVM instruction set; and,
- supports _precompiles_; and,
- doesn't require features from Rust `std` that we don't already use.
- capture execution of `LOGx` instructions.

Alternatives:
- original: https://github.com/ETCDEVTeam/sputnikvm (probably out of date)
- used by polkadot: https://github.com/rust-blockchain/evm/ (fork still with active maintenance)
- any other version of SputnikVM you can find

Test:
- run contracts with both old/original and new EVM instructions
- some test contract calls must succeed.
- add some test contract calls, with contracts that fail.

Story points: 3.0
EVM on WASM: EVM kernel crate

Add a new sub-project to the trili/kernel gitlab project. It should
- have name `evm_kernel`; and,
- contain a `Cargo.toml`, and a `lib.rs` file; and,
- have a `kernel_next` function (defined using the `kernel_entry` macro); and, 
- a "cache" type.

Story points: 1.0
Add integration test for inputs

Goal: There is a above the Protocol level test that loads a [Test kernel] that that has input feature flag enabled and feeds at least 10 inputs.

For similar tests, see `src/proto_alpha/lib_protocol/test/integration/test_sc_rollup_wasm.ml`, especially `should_boot_computation_kernel` (above Protocol).

Somewhat related:
https://gitlab.com/tezos/tezos/-/merge_requests/6208

Story points: 1.0
lib_scoru_wasm: disallow exceptions in entry-point functions

See also [team meeting notes](https://www.notion.so/trilitech/Meeting-Notes-a744673f343b4e328bf5bf14536c614d#6bbf9ac486ad452c9e5353c85cf3bac2)

Remove the mention of exceptions from `lib_scoru_wasm` `Make` signature. Add `try_with` or similar to catch exceptions and put the machine in a stuck state instead.

The machine is stuck whenever there is an error state in state tree accessible from `get_info`. A stuck PVM should not advance (meaningfully) but will increment the tick counter (only).

Optional: add another case to `Protocol.Sc_rollup_wasm.status` and propagate.

## Context 

The top-interface exposed in `lib_scoru_wasm` (e.g. `Make`) is called from the Protocol, where Ocaml exceptions are avoided by conventions. We must therefore catch and wrap Ocaml exceptions either in `Sc_rollup_wasm` or in `lib_scoru_wasm` (or both, defensively).

We nonetheless need to deal with:

- Non-recoverable errors caused by bugs in PVM
- User errors such as posting a syntactically invalid kernel

In the PMV 1 milestone we're not implementing a fallback mechanism, just putting the machine in a stuck state - though we should try to be future-compatible with error recovery. 

Note that internally in `lib_scoru_wasm` we can still use exceptions or error return values - but they should not propagate to the top-level.

Story points: 1.0
Make 1-module assumption explicit and test that it works with host functions

The following discussion from !5744 should be addressed:

- [ ] @hans.hoglund started a [discussion](https://gitlab.com/tezos/tezos/-/merge_requests/5744#note_1014886493):  (+3 comments)

    > If we ever add support for >1 modules we'll need to be careful to look up the blocks in the correct module instance.
    > 
    > The current state is OK, but perhaps worth adding a warning somewhere.

Story points: 1.0
WASM: intricated typechecking during parsing and evaluation

During parsing and evaluation, some form of validation / typechecking is done which makes the parser / evaluator convoluted and non tickifiable without tricks. The testsuite rely on these tests at this specific stage of the parsing / evaluation routine, therefore it cannot happen later. Especially, some modules in the testsuite are syntactically invalid since the test is supposed to fail during the parsing.

- Decode: local variables https://gitlab.com/tezos/tezos/-/merge_requests/5610#note_1008186757

- Decode: no free variables in functions

- Eval: checking type equality at call site when importing module

Story points: 5.0
SCORU/WASM: Ensure "unsafe" functions are never used inside the PVM

The interpreter can rely on unsafe or unstable functions that are only used in the executable part, for the testsuite or debugging.

- `Lazy_map.loaded_bindings` and `Lazy_vector.loaded_bindings` can be one of these functions (see discussion https://gitlab.com/tezos/tezos/-/merge_requests/5552#note_1017555842).

- Other functions like this include `Lazy_vector.{to_string,pp}` and `Lazy_map.{to_string,pp}` and any function whose docstring says "witness to internal mutation"

- `Valid` assumes the AST is always fully loaded.

- `Encode` assumes the AST is always fully loaded.

- `Free` loads vectors entirely, hence would produce huge proofs if used in the PVM. It should only be part of `Valid` and never used in the PVM, except for one specific part that is used in the parser (#3387)

- Various AST printing functions relies on `loaded_bindings`, and are only used by the final binary to produce debug traces.

- Pretty printing of lazy containers exposes internals and should bnot be used by the PVM

We need a way to ensure these functions are never called in the PVM, either by linting, tests and/or packagin. One possible suggestion can be found in https://gitlab.com/tezos/tezos/-/merge_requests/5552#note_1017690451

Story points: 5.0
SCORU: Wasm: Show that proof size is bounded

Goal: We have enough confidence that tick size bounds are not exceeded by Wasm PVM to enable the feature in mainnet.

Needs to be supported by "pen-and-paper" reasoning or better (fuzz-testing alone is not enouggh).

- [ ] `Decode.find_vec'` and `Decode.find_single'`, see discussion https://gitlab.com/tezos/tezos/-/merge_requests/5552#note_1013344663

Story points: 5.0
SCORU: Wasm: Add kernel loading logic to PVM

 
## Goal

Extend the Wasm rollup state with `/parse_state/input`, which stores a Merkelized list, or `Chunked_byte_vector` and a field `booter`, storing a `Public_key_hash.t`.

During origination, the originator sends the `booter` and an optional initial boot sector chunk.

When the machine is in preboot, incoming inbox messages are parsed as `{ next_boot_sector_chunk : string, signature : Signature.t }`. The signature is checked and the chunk is appended to the boot sector.

Whenever `next_boot_sector_chunk` is empty, the boot state is moved from `Loading` to `Parsing`, then proceeds with the normal boot process.


## Alternative

Put this logic in the SCORU protocol https://hackmd.io/ugX9U_CPTXOeB3Tk7ZPgFA?view. 

Believed to be more involved due to storage.


## Context
During work on https://gitlab.com/tezos/tezos/-/milestones/86#tab-issues it has become clear that realistic kernels are not going to be smaller than ~2MB, which is in conflict with the (block-driven) size limits imposed in https://gitlab.com/tezos/tezos/-/issues/3054.

This could be worked around with self-upgradable kernels, but this is out of scope for https://gitlab.com/tezos/tezos/-/milestones/83#tab-issues, hence we lack the capability to test realistically sized kernels. We here work around this by adding "append boot sector" logic in the Wasm rollup itself.

On finishing https://gitlab.com/tezos/tezos/-/milestones/83#tab-issues this logic can be moved from L1 to Kernel code if desired.

### Data structure
We need lazy append. That is (append M N) where proof size is O(log M*N), and better than O(N).

Merkle list might be tricky, because consuming from the front means rewriting the entire KV structure for that list within the tree. Morally you need a reverse-linked merkle list.

You can't use Irmin move opeerations, as with the set/get pattern, indeed you risk not recognizing the shallow move in set and rewriting the entire structure. The easiest solution is probably an indexed map of pages, boxed with an offset for the parser state.

Story points: 0.0
SCORU: Wasm PVM: Handle the right number of inputs per commitment

Goal: The Wasm PVM handles the right number of inputs per commitment.

A commitment period is split into L parts, each corresponding to an inbox level with a non-zero amount of messages.

For each part of the commitment period, `kernel_next` may be called up to N (tbd) times.
After which, the PVM defaults to consecutively reading inputs from L1 until reading an input from a subsequent inbox level. The loop continues after that. 

This means each section of the commitment period, has a phase to process the previously accumulated and a phase to gather inputs for the next loop.

Story points: 3.0
Wasm PVM: Remove duplication in input proofs

The following discussion from !5416 should be addressed:

- [ ] @hans.hoglund started a [discussion](https://gitlab.com/tezos/tezos/-/merge_requests/5416#note_964475159): 

    > ```suggestion:-4+0
    >     (* TODO:
    >        The tree proof contains enough information to derive given and requested.
    >        Get rid of the duplication by writing the projection functions and
    >        removing the [given] and [requested] fields.
    >     *)
    > ```

This should improve the size of input proofs by a factor of ~2.

Story points: 1.0
Dogfooding > Set up tracing in Jaeger

* Set up [Jaeger](https://www.jaegertracing.io/) and configure your application using one of the client libraries.
* Navigate to your project’s `Settings > Operations` and provide the Jaeger URL.
* Click Save changes for the changes to take effect.
* You can now visit `Operations > Tracing` in your project’s sidebar and GitLab will redirect you to the configured Jaeger URL.

Story points: 2.0
Highlight selected heading in markdown

If you link someone to an anchor link that is at the bottom of the page, scroll doesn't go all the way there. 

e.g. the following link for Sourcegraph, but has the 'Localization' heading at top of screen https://gitlab.com/help/user/profile/preferences.md#sourcegraph 

![Screen_Shot_2019-11-25_at_9.29.51_am](/uploads/5ecab00a475b7499e670891f830384b6/Screen_Shot_2019-11-25_at_9.29.51_am.png)

Would be great if we could highlight/outline/underline or somehow indicate that the sourcegraph heading is the target. i.e.

![Screen_Shot_2019-11-25_at_9.30.45_am](/uploads/710e58a30b83a5c5783dab5e7c698cd5/Screen_Shot_2019-11-25_at_9.30.45_am.png)

Story points: 1.0
Explore the possibility for a more compressed view of tables

When we were discussing how to utilize our existing table design to display logs, our engineering team suggested it would be better to have a view of the tables with minimal padding around the content so that users can view a maximal amount of content display onscreen (https://gitlab.com/gitlab-org/gitlab/issues/5696#note_244598777). 

Should we consider a more condensed table view? Or, should we allow users to swap back and forth between our normal view and a more condensed view?

Story points: 2.0
Set up monitoring for design.gitlab.com

This project has been moved to running off of a Kubernetes cluster using Auto Devops and internal Operations tools. Right now it is using the out-of-the-box monitoring configuration. This is insufficient for production troubleshooting, as we discovered when troubleshooting this ingress issue: https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/8319

This issue is to discuss setting up additional monitoring and metrics to increase visibility into the deployed instances.

The ingress issue that we have been seeing centers around the number of incoming connections, so as a first step, it would be nice to have some metrics for the NGINX Ingress controller's incoming and backend connections and their latency.

Story points: 2.0
Specify positioning and sizing guidelines for modals

### Problem

Modals across the product vary in size. Besides this, modals are missing some guidelines regarding positioning and sizing which could be useful in cases like the modal used for querying, listing, and filtering projects in https://gitlab.com/gitlab-org/gitlab-ce/issues/65285#note_213633672.

| Modal 1 | Modal 2 | Modal 3 |
| ------ | ------ | ------ |
| ![modal-milestone](/uploads/d46df0d55dcf19b9dc5d48a242614a8e/modal-milestone.png) | ![modal-upload](/uploads/520bc72485af92ef51c0211e089ab1c3/modal-upload.png) | ![moda-dashboard](/uploads/cf9b878d096c246e87cd27c9f8f5438e/moda-dashboard.png) |

### Proposal

Let's add some **positioning** and **sizing** guidelines  for modals.

Possible additions:
1. Specify space on top and bottom
1. Specify height growth strategy if needed 
1. Specify max-height
1. Specify listing guidelines and paginating through elements
1. Specify filtering options (filter box)

Story points: 2.0
Remove banner from sorting component

We've implemented a first-pass of the sorting component. We weren't able to finish styling the component because we are waiting on other components to be completed (https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/issues/274, https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/issues/281).

Our plan is to add a "this component does not yet conform to the correct styling" banner to the vue component on design.gitlab.com. This issue is to remove that banner, when all of the resulting style issues have been resolved.

![Screen_Shot_2019-08-22_at_10.29.48_AM](/uploads/16f28c6207fe71654011760012a7d45d/Screen_Shot_2019-08-22_at_10.29.48_AM.png)

Story points: 1.0
Create, Build, and Style > Drawers

This issue is to complete the ~"pajamas::create", ~"pajamas::build", ~"pajamas::style" portion of ~"component::filters" as part of FY20-Q2 OKR to Improve the quality and consistency of our UI.

This includes a single-source-of-truth component that is implemented in Vue and thoroughly documented on design.gitlab.com. This does not include implementing the component throughout the product.

Related epics:

* [Components of Pajamas Design System:
* [Pajamas component:

Related issues:

* [FY20-Q2 UX OKR: Improve the quality and consistency of our UI](https://gitlab.com/gitlab-com/www-gitlab-com/issues/4355)

## Checklist

* [x]  Usage documentation is included in Pajamas
* [x]  Component is built and styled in gitlab-ui according to specs
* [x]  Add the design specs to Pajamas https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2719
* [x]  [Create Drawer structure in Figma](https://www.figma.com/file/2XRq1MnIG69iti76Mh9HpJ/branch/DlBySFafHmSJEzgJv2v2Sa/Pajamas-visual-examples?node-id=3487%3A15479)
* [x]  Add the structure diagram to Pajamas ([Figma branch](https://www.figma.com/file/2XRq1MnIG69iti76Mh9HpJ/branch/DlBySFafHmSJEzgJv2v2Sa/Pajamas-visual-examples?node-id=3487%3A15479)) [MR](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2737)
* [x]  Remove the banner on vue tab that warns of incorrect styling ([MR](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/2677))
* [x]  Add a reference and link to the completed component in the [Engineer Week in Review](https://docs.google.com/document/d/1Oglq0-rLbPFRNbqCDfHT0-Y3NkVEiHj6UukfYijHyUs/edit) doc

Story points: 5.0
Follow-up from "WIP: Resolve "Review illustration documentation" - Add link to icon naming

The following discussion from !1506 should be addressed:

- [ ] @tauriedavis started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/merge_requests/1506#note_202920888):  (+3 comments)

    > Is it possible to link `icon naming` to a section that describes how to name icons?


Dependent on https://gitlab.com/gitlab-org/gitlab-design/issues/554

Story points: 1.0
Define default delay for popovers

### Problem

> At the moment, we don't specify a global delay for any of our popovers - each popover instance specifies its own delay (if any).

### Further information

> Looking through the source, I was able to find two places where we manually specify a popover delay - both are `200ms`. For example: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/user_popovers.js#L98. This is the popover that shows when a user's name is hovered.

### Proposal

After https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/issues/235#note_195974856 has been concluded, we should look into improving this for popovers as well.

Story points: 1.0