Access Control -- task running 1st time, failing the 2nd time

Raising @guix’s question from github here: Secret Access-Control · Issue #1 · scrtlabs/EnigmaBounties · GitHub

Here’s the project so far: GitHub - guix77/enigma-secret-access-control
I’ve implemented it as multiple messages, since 1 thought one would not make sense either for tests or UI. But when I’m trying to get Bob to read again his messages, his tasks fails whereas it does not fail the 1st time and it’s the same code (enigma-secret-access-control/test/test_secret_access_control.js at c15e9ac6a723c368e03c7dd42f738d53123836d9 · guix77/enigma-secret-access-control · GitHub)

Question is why the task fails when Bob tries to read his message.
And just for clarity, @guix can you describe the data flow of the secret message in your implementation? That would be really helpful for me. Thank you!

I’m having maybe a similar problem when trying to write tests: I have an array of two strings returned from a function -

expect(web3.eth.abi.decodeParameters([{
192         type: 'string[]',
193         name: 'names',
194     }], task.decryptedOutput).names[0]).to.equal('test_dataset');

if the array only has one value [“test_dataset”] this test passes
if the array has two values [“test_dataset”, “test_dataset2”] and I try to index the first one for comparison it fails with

AssertionError: expected '\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\ftest_dataset\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u000e2test_dataset2\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000' to equal 'test_dataset'
      + expected - actual

      -
       test_dataset2test_dataset2
      +test_dataset

      at Context.it (test_secret_validation.js:194:44)
      at processTicksAndRejections (internal/process/next_tick.js:81:5)
2 Likes

Hi @guix, can you look at your discovery log and see if there is an error after that 2nd request to get Bob’s messages? This is what I’m getting when I run your tests.

Output from discovery test is:
revert Wrong epoch for this task

And thediscovery start log has this error:
Unable to get keys: Operation not allowed while the EpochState is transitioning. Current state = UNCONFIRMED

Are you seeing the same thing?

Hey @guix,

I was able to get your 2nd request for Bob’s messages by changing the gas limit and gas price to what I saw in the Getting Started tutorial that @adi wrote (https://blog.enigma.co/getting-started-with-enigma-a-front-end-demo-for-dapps-bc694d3d81b9):

const taskGasLimit = 10000000;
const taskGasPx = utils.toGrains(1e-7);

The discovery log indicated there was a gas limit violation.

@izokay I’m seeing something similar. It’s like it’s returning the entire vector in names[0]. Let me know if you’ve figured this out already?

1 Like

yes same problem. haven’t found a solution

still looking into this @izokay.

@izokay and @laura,

I confirm that vector of dynamic types (vec<vec> and vec) isn’t supported by the Engima Protocol at the moment, we are working on this to support it, but the earliest we may have solution is two weeks out. Most of our team working on this front is preparing to attend EthBerlin next week, where we’ll give several talks, workshops and meetups.

The best workaround that I can think of at the moment is to implement a custom workaround by manually concatening to one string/vec. Say by either establishing a known delimiter a priori, and doing a string splitting by that delimiter; or alternatively have a string that stores the lengths with a known delimiter and a concatenated string that stores the actual values.

We will update this thread once we come up with a more formal solution.

3 Likes

good luck at ethberlin. I like the delimiter idea - will try it

Hi,

Sorry for answering so late, I took a few days off. And thanks for all your answers :slight_smile:

  1. @laura Thanks for the gas limit tip, I took care of the price already but that was indeed the problem Bob’s second tx.
  2. @laura @izokay @victor Yup, it’s not working but coming from Solidity I should have suspected problems with string arrays anyways. One of @victor’s workarounds seems to be the way to go for now.
1 Like

So, I first tried @victor’s 2nd proposal which I consider best, using a concatenated string and an array of u8 string lengths, returning a tuple: https://github.com/guix77/enigma-secret-access-control/blob/c6e0938619d547faf1d8dcbaf64298db53d1dc41/secret_contracts/secret_access_control/src/lib.rs#L54

While it compiles and migrates, and worked in a simple independent Rust implementation, in the tests I was always getting null for task.decryptedOutput.

I looked at all ESC examples and could not find any example of a function returning a tuple. I would be interested to know if it’s possible.

So I switched to using a separator to avoid wasting too much time: https://github.com/guix77/enigma-secret-access-control/commit/fcd721f891d18c8d5e5d06c3e7dc03af8e898f7f

2 Likes