As we get settled in, we'll start protocol office hours in a bit.
I'm sending you an invite to speak as well.
The team is slowly getting in.
The core protocol team, Pagoda.
And in good notice, I'm Nico from the overall team as well behind the Pagoda name today.
And I'll slowly leave the floor to Josh and Chetna and Jacob who will be hosting protocol office hours today.
If you haven't noticed, I'm Nico from the local team as well behind the Pagoda name today.
and Chetna and Jacob will be hosting Protocol Office Hours today.
All right. I'm sending anybody to speak to you, Jacob. I think if you're not on your phone,
you should join from your phone to get the invite. And we can get started if you want Chetna.
Yeah. Hey, everyone. Thank you for coming in. And probably more folks will trickle in
here in a few minutes while we get Jacob up on the stage. So I would highly, highly recommend the
ones who are listening to actually, we had tweeted yesterday also about some of the things that we
wanted to discuss about the topics, which is going to be metatransaction and another NEP that
Jacob himself is working on, who is from Pagoda. So before we start there, so please do take a
survey that we briefly shared yesterday and also last week, which will give us or give the community
a platform to actually be active members and provide voice your ideas and feedbacks at the protocol level.
So again, I want to remind everybody, so this is very focused protocol office hours. We do have
other office hours which are focused on dev, dev platform, dev tools and such. This is
fundamental layer protocol. So yeah, so we would highly suggest everybody who has questions to raise
hands and also make your question very focused on the protocol. And we're happy to answer or direct you
to navigate other areas. But yeah, here we want to just focus on the protocol. So yeah, with that,
what do we do is, Jacob, I hope you can actually use the speaker. Hey, Dennis. If you can, Jacob,
go ahead and introduce yourself so that we can get started. Hello, everybody. I'm Jacob. Is my microphone fine?
Yes, sounds good. Yeah. Yeah. Working for me. Okay. Yeah. Just making sure I got all the permissions right
here. Yes. So welcome everybody. The introduction has already been done for like, what are we going to do?
Please really ask questions. I want this to be interactive. But I'm also just happy to talk about
tech as long as you don't stop me. So yeah, I'm working in the protocol team, more specifically in
the contract runtime team. But yeah, the boundaries are somewhat thin and we can work on any kinds of
features that are interesting. And today I'm going to talk about metatransactions as a first topic.
So let me back off a bit and define metatransactions first. And then we'll talk about why this is
actually useful and a big step forward for what we can do on near. So yeah, metatransactions are like
normal transactions. So we're talking about not only near token transfers, that's one type of transaction,
but any function call that you can do on near or like the creation of the account or anything like
that. All of these are transactions. And usually when you make a transaction, that all happens within the
frame of the frame of one account. So you send your actions that you want to be executed, like please send
some, let's say some sweat coins from one account to another. That's a fungible token transfer. That's one transaction.
And it all happens on the, on sweat coins token account. So you only have the option to submit this
transaction. And then it will be executed all in one go. Like you, you can have cross transaction,
across short calls, like across contract calls, that's the right word. But it's still kind of originating
from this one account that signed it, that is paying all the gas fees.
What metatransactions allow is now to wrap a transaction inside another transaction.
So what you can do with metatransactions is you, you create the transaction off chain as you usually do,
but instead of sending it to the chain directly and execute it there, you send it to a relayer.
And the relayer will wrap this transaction for you inside another transaction. Now that transaction,
wrapped in another transaction is a metatransactions, you can send that to the chain. And then the relayer
pays all the fees to execute both the wrapped transaction and like the outer transactions both together.
And on chain, it will be kind of unpacked and it will be checked that yes, indeed you signed this transaction.
So the relayer cannot just execute any transaction for anyone, like you had, you still have to sign it,
but that the relayer can pay for it. And that by itself doesn't sound all that impressive, maybe.
But if you think about it, now you can have someone else paying for the transaction.
That means you don't need an account on the near blockchain and you can execute transactions on the near blockchain.
So let's say you do have sweat coins, but you don't have a near wallet and you don't have
an account traded on the near blockchain. So what does it mean to still have sweat coins that are stored on the chain?
Because inside the sweat coin contract, there is an entry that says,
yes, that public key that is associated with you, you hold the private key for that.
That key has some tokens, but it doesn't actually have a near account created on chain.
There is an implicit account that belongs to you and you can prove that it belongs to you because you have the private key.
But you haven't created that account because when you create the account, you actually have to pay
some gas fees and you have to pay for the storage on chain.
So it's kind of a weird thing, but you can have an account that doesn't even exist.
That's the same with other blockchains like on Bitcoin, you just create your account and you have it.
You don't have to store anything on chain. In near, you can actually create it and then it will be
stored on chain, but you don't have to do this with meta transactions. You can just have
an implicit account and use the relay to pay for your gas fees and then you can execute any transaction
you want, like sending fungible tokens from one account to the other. It gets even more interesting
once you start to kind of combine use cases. So what you could do is say you actually pay
the relay some of your sweat coins as a reward that they execute the gas fees for you.
So you can kind of purchase gas that you usually have to purchase with near token. You can now
ask the relay to purchase it for you and pay with sweat tokens to the relay.
And I've used spice coin as an example, but it could be like USN, it could be any kind of fungible token
that that's hosted on near. And we believe that that's going to be a huge difference for the,
for near protocol as a whole, because the onboarding just becomes so much easier. You don't actually need
a near wallet and the near account to use the blockchain in a useful way to you. And that I think
is something we're working on right now. We really want to push this to get it done. Lots of technical
details to get right to make sure all use cases are possible, but also safe.
So I haven't been implementing a lot of it, but just reviewing it and helping out thinking it through.
And I think at this point, I've given you like the overview. So awesome. Yeah. Yeah, no, no, I was
going to say, I got a question, but I know Dennis has raised his hand and has and has a question. And
yeah, I just want to let everyone else know, just raise your hand if you have a question and I'd be
happy to bring you up on stage and ask Jacob as well. But yeah, Dennis, go ahead. And then I have
something that I have a question. Yeah, I actually have three questions. The first one is, what is a
relayer for dummies? The second one is, if the payment can work for any NFT in this relayer? Is it
then the responsibility of the developer to implement the relayer logic as to accept payments in the NFT
and convert that to near? How will that look like? And the third one, I just quite forgot. So let's just
keep these two. Yeah. Yeah, I'll just answer them one at a time anyway. So that's perfectly fine.
Thanks, Dennis, for the question. So what's a relayer? Very good question. I just glanced over it.
So the relayer is really something that whoever provides this has to kind of implement it for
themselves. For now, we're just giving this opportunity, like we're just making it possible.
So the exact details of what reliers will be, we still have to figure out. But in this, essentially,
what you have is some server running somewhere that is accessible off-chain. When I say off-chain,
I mean like web tool technology, basically, you can send a request to that through a normal webpage,
through your app, it's basically up to the relayer provider, how they want to make this accessible.
And the relayer will then communicate to the blockchain like a proxy. So you will accept your
transaction and relay them to the to the network. Yeah, does that explain things a bit more? Or like,
do you have more questions? So you're basically saying like,
a relayer is an off-chain, it could be an off-chain website, like that you log into,
and then they are doing something on your behalf, you're defining relayers as somebody else that's
doing something on your behalf, via on-chain or off-chain, but it's really up to them to
decide the implementation. Am I understanding that correctly? Yes. Yeah, you phrased that much
better than I did. It's really just the website. Okay, no, no, it's all right.
Yeah, that looks like... Okay, so it could be a variety of ways in which you can implement,
but basically someone else that's doing this on your behalf. Dennis, does that answer it for you? Do you have a
follow-up to what is a relayer question? Yes, I have follow-up questions, but I'll complete
my two questions, and then we can go to your questions, Josh, and I'll come back to this one.
I'll make a note of it right now. All right, thanks. All right, all right.
So the second question, what was it again? Can you remind me?
I think it was around, does the developer implement the relayer code?
Yes. I think I almost kind of hinted at it already. It's like, yes, the developer has to
implement this. At this point, we are not even designing a standard for it. So at this point,
we're defining the standard for meta transaction and make sure these work
properly. And the relayer is something, is a use case that we're thinking about
that motivates this. But we still have to kind of figure out if maybe we want to have a standard
that defines how this should work. But maybe it's not necessary, because it's really kind of up to
the developers. Like, not necessarily smart contract developers. They might be able to use
existing relayer implementations, but some people will want to implement that. And it doesn't have,
it's not a protocol feature itself. So I hope that kind of makes sense to kind of,
so for me, as someone working the protocol team, that's something that's like outside of our realm,
as a user perspective, it doesn't matter so much where it is. But it's to understand the stages of how
we're implementing this. It's really just make the foundation, make sure there is a possibility to
implement every layer, and then let the community have a go at it and find what works best for them.
As long as we give them the tools, they will find a way to build it.
Yeah, that's how I see it. Dennis, do you think that makes it clear?
Yes, it makes sense to me. I think a quick follow-up remark, not a question, but what I'm thinking
right now, it would be nice indeed to have those standards out there, and maybe a simple example
of how an app can implement this free layer logic with their own server as to, yeah, minimize their
gas costs and make their user experience much easier. Yeah, yeah, that makes sense. There is
already like, in the NEP where we are discussing this implementation of meta transactions,
we already have like a diagram that shows how a relay works. And I can see this evolving into
into more details as we as we move along.
Yeah, yeah, we're speaking about NEP 366, right? The one the meta transactions ones that was opened by
Ilya back in June. Is that correct? That is correct. There is an extension to it that's not merged
in yet. So if you're reading 366, you're not getting the full picture, but it's mostly correct.
If you want to see the image, you should look at 422.
Ah, 422. Ah, I see your comment at the very end.
Yeah, and for those wondering, if you go to GitHub, and you go to the Nier organization,
and NEP's repo, we're looking at pull request for, well, I was looking at 366, and at the very bottom,
Jake has a link to pull 422. So GitHub, forward slash Nier, forward slash NEPs, and then the pull
requests. Cool, so the diagrams there. My question was kind of going to, when you're talking about how
this relayer can pay for this transaction, um, on behalf of the user, um, and it'll cover gas costs,
which, but I didn't, um, I, I'm, I'm missing the disconnect of like, who's putting the storage,
because like any, any kind of, you know, fungible token contract, you're going to need to store that
key value pair of the implicit account that doesn't yet exist. Uh, but that, you know, this implicit
account owns two fungible tokens, or whatever it is. Um, who's putting the bill for, for that? Is it
the relayer? Is the relayer paying for storage for people? Uh, I think, yes, like that, the
straightforward answer is yes. The relayer has to kind of pay for everything on chain. Okay.
You, you want to make sure that you actually get something back for that from the user, right?
Depends on the, on the model, but what you're thinking of is when you send this transaction,
a relayer can make it a necessary condition that this transaction contains
also a transfer of tokens to the relayer, uh, or fungible tokens, not, not near tokens, but
let's say USN. So they need to receive USN, uh, and only if that's a part of the transactions,
will they actually relay it? Because remember like a transaction can contain multiple actions,
right? So you, you, you can do whatever you wanted to do. Plus also you're actually going
to give a payment to the relayer. So yes, the answer is the relayer pays for it as far as the
blockchain is concerned, but the relayer can make sure they, they get it back.
Hey, we should take a questions on stage because we added a two more folks on stage. I think Patrick
was the first one to join. Um, hi Patrick, go ahead and introduce yourself and, and go ahead and ask
your question also. Hey, yeah, I'm Patrick. I work on, uh, um, near some new projects here in the ecosystem.
And, uh, you know, one of the questions I had was, uh, on, um, RPC configurations and documentation on
that. So, um, you know, if you go to near nodes and you look up RP setting up an RPC node, um,
there's a lot of customizations you could do with config.json, but it's not, uh, uh, easy to find
that documentation. Um, so is there a place I can go find that? Um, and I have another question.
Uh, well, okay. Then I guess let's talk about the near RPC config first. Um, so what exactly are you
you looking for, like, are you looking for specific RPC requests like endpoints?
So the generated config.json, right. Uh, it has a bunch of like, you know, keys, uh, with, you know,
with values. And, um, the only thing that I could find documentation on was tree viewer state size limit,
which I needed to modify, uh, for my custom RPC node, because my, my transaction was too large,
uh, for the normal public RPC nodes, uh, but I noticed a whole bunch of other fields that I
don't know what they do, the actual values for them. And I wanted to know where I could find
documentation on that. There's also genesis.json that gets configured. There's also, uh, trusted
boot nodes that's documented on near nodes.io, but if there's no, uh, those notes, there's no definition
as to what a trusted boot node even means. Um, so yeah, that's, yeah, yeah, I hear you. Yeah. Yeah.
Um, a genesis.json, you shouldn't change, um, but config.json, you definitely have,
have the right to change. And, and that does make sense. Um, I think it, there is actually no
good documentation on it. Like I can tell you to look at the code directly and we have comments on each
field. That's kind of how I would get the information. Um, yeah. So if you could link,
uh, you know, on, in discord and pin it, uh, of where I could find it in the source code,
that would be even helpful because near core is a mono repo and, uh, it has like a, you know,
a variety of things that it does. So it would be nice to know where I can find this information
easily. Yeah. Yeah, definitely. That's, that's fair. Uh, I can, I can send you that link, um,
on discord, um, probably after this call to make sure I get the right details, but yeah,
that that's, that's something I can do unless like maybe defro someone from you knows about better
documentation option about this, but yeah, as far as like the no duck yet, the no documentation
devrel doesn't, um, contribute to, uh, we basically have docs.near.org is our area of ownership. Um,
and we've helped out, uh, in migrating the indexer documentation, uh, into docs.near.org and sunsetting
the, the indexer standalone doc site. Um, but yeah, as far as the no documentation, we don't have,
um, uh, we don't contribute to, um, but I can, yeah, definitely ping, um, someone on that team to,
um, to kind of help you help you find that, find that out. And also, yeah, uh, happy to, uh, relay this
feedback to them. I think that's really enough protocol team. So I just didn't know if I was maybe
not aware of some resources here, but, uh, we, we should, um, document it better. And we're really
like trying to, to work on documentation more and more. We were building an entire guide. It's like a
book about near core development. That's just like getting around. Yeah. That's in the repo itself.
Right. In the, in the docs, there's like a docs folder in the near core repo that you guys have
been working on to help, uh, uh, document how to contribute to near core. Correct.
Yes. Um, but it's also like hosted and rendered at near.github.io. Um, there you get like
everything rendered there, but it's still kind of being filled in with details and we, we have to
make sure it's actually listed somewhere that people can find it. But I would imagine that now that we know
we need to kind of also, um, document the conflict or chase and that's missing, that's something that
we can kind of integrate into this documentation. So hopefully in a few weeks, uh, at the latest,
you will kind of have something like that. In the meantime, I'll just send you the link to where
it's defined in a code. Awesome. Thanks. Thanks Jacob. Mike, uh, I believe you have your hand raised.
Thanks. Hey y'all. Super good to see everyone here. Um, happy, happy Wednesday. Um, I, yeah,
this is super, uh, intriguing for me about meta transactions. Cause this is a subject I haven't
really played with. I know that on a, this has been around on Ethereum for a while and people were
really excited about it. Um, so, but I, I've never actually truly understood it. And as you're
explaining it, Jacob, by the way, that's amazing, like, um, amazing explanation. Um, like one,
one thing that comes to mind is like, like, so re replay attacks are like, you know, a very scary
thing. And that's kind of why you have nonces and just to sort of dumb it down. It's like,
so if Mike.near wants to send someone like 10, 10 near, then I have signed it with like an
increasing number. Like the first time I send someone money is going to be one, two, three,
and that will kind of like scramble my hash basically. So no one can just like say, okay, I,
I've intercepted the message where Mike is sending someone a 10 near, I'm just going to give the
blockchain that same message twice. And then they get 20 near, right? Like, so you kind of guard
against that with this, uh, thing called a nonce. It's like an increasing number. Um, but now we're
talking about sort of like implicit accounts and then you have like a private key that resolves to a
public key. And then the implicit account is basically representing what that public key is.
But I'm not really understanding where the nonce kind of comes in here because I feel like that is
actually on the more like protocol account level. And we're kind of like sidestepping
the protocol account level and, and like the nonces. Um, so certainly I'm, I'm like missing
something here, but I kind of wanted to like hopefully tee that up and maybe that's enough
information to like, like start the question. Jacob, does that, is that fair?
Yeah, that's actually a very smart question. Um, that is probably the biggest question we had
to in kind of how to implement this. And our solution right now is to not sidestep the accounts.
That means we actually require the account to be created. So what I, that means for the relayer,
if, if you want to execute a transaction on an account that does not exist yet,
then the relayer has to pay first to create this account. And then it can behave on like it can
execute transactions on that account. But once we have created the account, we can store these nonce
transactions, um, in the account, um, and then we can prevent, uh, replay attacks in this way.
We are aware of a couple of corner cases where this, um, can be quite inconvenient for the relayer.
And we do have a number of, of options, how we can kind of work around it. If you really are like
interested in the very specific technical details, I encourage you to read through our discussion on
the NEP. Um, but the, the TLDR is like, we don't have a really satisfying answer yet. And we would
love to have some input of more people thinking about this for now, which is required account to
exist. That is kind of the easiest way to go around because then you always have this nonce and
things just work out. We kind of put the burden on the relayer to, to pay for account creation.
Um, yeah, very cool. I love that. So there is a protocol account like in there. It is just kind
of created by the relayer first and they're doing that. Yes. That will be the solution for now. If you
want to follow this model. Yeah. We hope to kind of get away off the, from this, but exactly for a
reason you mentioned kind of not that easy to do. Interesting. And then if I can just have a quick
followup. So I'm, this gets really curious when it's like, I want to like, I'm willing to pay you
two sweat to be a relayer for me. I'm willing to pay you three sweat. And so there's probably some
mechanism where the person who doesn't have an account, who is going to give a message to a relayer,
like encode some information about how much fungible token I'm willing to give you. Um,
and then they, I guess that part is a little confusing to me because there must be like,
you know, I'm willing to give you one or two and what is the fungible token? It's going to be sweat.
So there's like information there, but then at some point the protocol is like subtracting that from
this person's account who doesn't have an account. Um, I, I, I, I'm not sure if that's a weird way
of asking, but I'm curious. Yeah. Yeah. Yeah. Yeah. That, that is need some more explanation. So, um,
are you talking about your metadata on your meta transaction?
So quite fundamentally you want to send, uh, this transaction and you will only have to execute it
by someone else. So yeah, somehow you have to pay for it and you have to agree with the relayer,
how much the relay will get from you. And the way you do it is it's not that complicated.
Uh, you have to send the relay your transaction and sign that you actually want to execute.
And again, remember a transaction can contain multiple actions.
So what you do is you fill the transaction with all the actions you want to actually execute,
whatever it is you want to have done your transaction and you append one more action.
And that action is, please make a fungible token transfer, uh, from my account where, um,
and the receiver will be the relayer.
Does that make sense? Um, I can elaborate a bit more, but like, that's the fundamental idea.
Awesome. Yeah. I appreciate that. Uh, uh, thank you. I'll definitely be looking more into this.
It's really, really neat stuff.
Okay, cool. Um, I think Patrick had a second question that he didn't have the chance to ask.
All good. All good. Yeah. I was just, uh, curious how, uh, what the best practices on like,
um, like cross contract call tracing is, um, where I don't want to have log information on chain, but
because I feel like if I record log information on chain, wouldn't that affect, uh, my gas calculations?
And, um, yeah, I just, I want to basically have that off chain. So is there a way where I could specify,
um, some kind of like, uh, like, like, you know, inside of my wasm, like have a sidecar that,
that basically admits logs to like data dog or something like that. Do you, like, what, what,
what do other people do, uh, in terms of like, uh, like navigating, like tracing and logging?
I don't know the answer to that questions of what others are doing. I know that you're right.
It, it will cost you some gas when you're emitting logs, but, um, any kind of side effect you want
to have from your vasm execution will cost you gas because the validators actually have to do that
work for you. And if you thinking about some, somehow like side setting this and sending it to,
to some node somewhere that receives this data, it's basically the same as, as writing logs, um,
a different way of doing it. It's in, in one case, it's actually storing
that on chain, right? So there's storage costs associated with storing that on chain versus
just emitting it elsewhere where there's an off chain storage, right? So I don't think it's
necessarily equal. So are you running your own node? Like, do you have your own node in the network?
Because if you have your own node, that node can kind of extract data for you.
But then all the other validators will not do that work.
But that's like a quite a heavy investment and quite a complex change to make. And I don't think
we really have a good, um, like, I know it's possible, but like the support for this,
it's probably not quite there yet that you could kind of change a node to emit the data that you're
looking for. And just to be clear, like, if you have logs, it's not stored on the smart contract
state. It is just like a very ephemeral thing, like that the validators who are probably only
keeping like, you know, let's say a month worth of transactions and logs that happened,
that will eventually like, unless you have an archival node that will eventually just get pruned.
So like, I guess this is kind of to Patrick too. It's just like, your contract isn't bloating at all
when you're emitting logs. It's just sort of like going out into a block and anyone in the future
can sort of like do forensics on what the heck happened like a month and two days ago at block,
you know, 62519. And then they can see the log that was emitted, but it's not like living as contract
state on your, you know, like forever. Right, right. Yeah, no, I'm just trying to like figure out,
like, I'm running into the gas exceeded limit issue. And I'm just, you know, making multiple cross
contract calls that are, and I'm just trying to like trace all of that stuff. So, you know, when I,
when I was asking on discord, the recommendation was to basically have all of this on chain.
Um, and then, uh, yeah, that's kind of how I went down this rabbit hole. And then I looked into
also like wasm and wasm. And I was curious how, what the, you know, what the best practices there
would be, uh, and how that would affect gas prices and so forth.
I bet you near lake would be good for that. Bogdan and for all would totally know. I mean,
if you look on Explorer, you can see like the cross contract call, like messages flying around.
So it's gotta be, be there, but it's like, it's hard to get to.
Right, right. And I have my own indexer set up that listens to near lake. So that's, that's all done.
Um, but if that, if that's the recommendation, I could just go ahead and emit logs and see how that,
how to trace, uh, in that way.
Yeah, I think that's probably the way to go. And like, to be clear, like logs, if you're not emitting
hundreds of lines of, of logs, that shouldn't really be the limiting factor on gas here.
Um, it's not that expensive. That's what I'm trying to say.
Is there a utility to help calculate gas, like potentially before you deploy?
I think maybe Dennis, do you want to answer that or?
I'm sorry. I missed the question.
Do we have utilities to kind of help estimating gas to figure out like,
like it was in the context of logs can take quite some gas costs.
Yeah. Um, we, I, I did set up a rest API that does exactly that. So, um, it's called
gas buddy. It's on my, yeah, it's on my, uh, personal, uh, GitHub. Um, but actually, uh,
what it does under the hood is it uses the testing library workspaces. Um, so workspaces has this, uh,
feature that allows you to, uh, spoon a contract from mainnet or testnet. And what this means
is that it, um, grabs the smart contract code and it deploys it on your local machine, uh, with the
data, if you wish. So, but that also has its limits and nuances. I will, um, uh, touch upon this in a
moment actually, but it spoons the contract code and the state and, um, then it runs the desired
function you want to run on it. Um, obviously a limitation is cross contract calls because you
will need all the cross contract, all the other contracts is going to cross contract call,
uh, uh, in your local, uh, uploaded into your local network as well. So, uh, but yeah,
another limitation is that, uh, you can only extract, uh, I think it is, uh, I, I don't know the exact
number, but you can only extract a max number of, uh, bytes of data from a contract state from
mainnet or testnet. Um, otherwise you need to point it to, uh, on, uh, a node of yours, uh,
which does not have these, these limits in place. I believe this is something you can tweak in the
config.json. Um, but, uh, yeah, so, uh, that's what GasBuddy does under the hood. If it's a very
simple, uh, JavaScript code, actually, I, I put it out there and it, uh, yeah, it has its limits,
for example, cross contract last units, a function will cost, uh, um, then you can, uh, uh, call the,
that rest API with the name of the account and the name of the function. And then it should tell
you how much that will cost in eight seconds. It takes a little while.
Cool. Thank you. Yeah. Check out, uh, workspaces and, um, uh, trying to find your GitHub repo, but yeah.
I'll add it, I'll add it to the comments. I'm gonna comment my GitHub repo here.
Cool. Any other questions from anybody?
Again, if you're in the audience, feel free to raise your hand if you have one.
Um, and Josh, I was also thinking like folks who cannot actually speak, maybe they're not using
the app. We should have a way to take questions. Um, maybe pre, um, solace it questions before
coming into office hours based on the topic, or they can DM us because they may not be able to
use a speaker option or whatever. Yeah, no, totally. I wish there was like a chat feature,
uh, uh, for this where we could kind of, uh, uh, ask for this. I guess you give a reply to this,
uh, the Twitter post. Yeah, exactly. Yeah, exactly. Maybe a feature for Elon Musk to help us out.
Cool. Um, yeah, more, more, uh, Dennis, did you have, uh, did you have follow-up questions to the
meta transaction topic that we were talking about? I know you said you had, um, some follow-ups. I'm
not sure if they were answered or not. Yeah, I do. Um, uh, but first I'm looking at how,
oh yeah, I, I can see the captions are typing in. Well, just to go back on the, on the GitHub.com,
I was looking for comments on this, uh, Twitter spaces thing, but I can't find it. It's basically
github.com slash idea 404. That's, that's my GitHub page. Otherwise I, I occasionally, uh,
I think my last tweet also dropped a link to my personal GitHub space. So, uh, you can look into
my profile and you'll find it. Um, and, uh, about the meta transactions, uh, yeah. So I was just,
just, uh, a little curious, uh, Jacob, what are, um,
um, why would we want to have this relayer and just not implement this in another layer of core
of the, of the core protocol say instead of, because I'm thinking, okay, people can have their
own centralized server where, uh, they'll do the, the, um, the, uh, transaction aggregation
or roll up, uh, or they could have another network, which they point to. And that has its own,
uh, um, thinking about many, many level twos that you have in Ethereum right now, for example.
Um, but I'm thinking that's not very, um, it's not very new, is it? Or, or pretty. Yeah. I do see
the value in it, but I, I think, um, have you guys explored also whether you want to do it in core
and, uh, yeah, or, or, or some, some other route you can take. And, uh, my second question would be,
um, yeah, what gets you, what gets you most excited about this, uh, meta transaction features
and, uh, what do you think can be improved to Boston?
Okay. Um, so the first question, I'm not sure if I understood 100% correct. So stop me if I go in
the completely wrong direction, but I understand you asked if we could kind of
remove the off chain relay and kind of have everything on chain, which obviously would be
much preferred, but there's like a fundamental problem that as soon as you start executing
something on the chain, someone has to pay for it. And, uh, the idea is that you can execute
something without having tokens, without having an account pre-established. So there has to be
an entity outside that will make the entrance into the chain, uh, kind of possible. If you,
if you don't have that, if let's say I don't have an account, but I can send the meta transaction
directly to the chain, and then the chain will start checking if it's actually valid, then this
kind of work that we're doing, who is going to paint to pay for that? If you want to avoid a case where
you can just spam these transactions without having an account and they're completely nonsense, but the
the chain, the validators running the chain, they don't know that before they start kind of, uh,
looking at what's inside and by having the validation part kind of done by the
relay, the relay will then sign that the meta transaction sent it to chain. And before we start
working on that, we will check that the signature belongs to an account that actually has the
tokens so that we can do the work. Um, so that's like the fundamental reason. Does that answer your,
your question here? Yeah, that makes a lot of sense. Yeah. Yeah. Thank you. If you, if you have ideas
how we can kind of move everything on chain, um, maybe also other protocols that have solved, then
please let us know. Like that would be exciting and exciting. Well, those are your second question.
What am I excited for here? I, for me, this is like a step towards mass adoption. Um,
so we have this vision of, uh, 1 billion users at some point in the future. I think we have a specific
date. Um, don't know it, uh, from my heart, but this is kind of what we need. Maybe it's not realistic
that 1 million users around the world will install a near wallet, but it is very, very much realistic
that 1 million different types of apps somewhere out there use near in the background and actually
represent data for these 1 billion users. Um, without meta transactions, I frankly would see
this as a much, much harder kind of goal to achieve with meta transactions. That's, uh, that seems like
a possibility that makes me excited. Um, I'm happy to hear what other people are excited for it. Maybe
I'm missing the, some other opportunities here. Like there's quite a lot of opportunities for meta
transactions, I think. I don't know if it is relevant, but like how, how unique the meta transaction
solution on near is like, is it agnostic of, I know other chains are also implementing meta transactions,
right? So, um, how is it unique or, or similar, um, to other implementation? I don't know if you have
looked at Polygon and few other chains, uh, they're not necessarily a one, but, but what do you think,
Jacob? Have you looked around and seen, um, I have to admit, I haven't looked at this. Um, I would love to,
I'm usually like quite curious about how other chains to do it in this case, been a bit busy with
many things. That's like one of a number of things that I just kind of ask, been asked to kind of
review it. So it's, it's a bit sad that, um, Igor, who kind of actually implemented to everything, uh,
is not in the call. I think he would definitely know how to answer that. Um, yeah, I, I can't really
give a comparison here. That's fair. Cool. Well, it looks like we're getting down
to the last 10 minutes. Uh, any other questions that anybody has, uh, for Jacob? Any burning desires?
If we, if we want to follow closer to the, uh, this conversation on, uh, meta transactions,
it's in the NEPs repo under the near organization, right? Right. Yeah. It's 366,
I believe. And then the, the 422 is 422.
Did you guys talk about the timelines for that? And I'm also curious about Wasm and Wasm if, uh,
there's a date for that as well.
So timeline for meta transaction is like as soon as possible. Everyone wants it now,
or better yet, we want it yesterday, uh, being a bit more realistic, anything we implement on the
chain and especially drastic changes like these, we have to be careful, consider every step and make
sure we're not breaking anything. So with that kind of in mind, I, I hope that we can finish
all the implementation by the end of this year. That means we will have, um,
um, the, the, the, this implementation where the relay has to kind of create the implicit account
first and only then will it actually work. Uh, that will be kind of the constraint we have,
and we will try to come up with a better solution for that later on, but it will already work in
principle. And then we also have to kind of enter the testing phase. So my kind of engineering
perspective here is maybe we can get it on test night in January. And in that case, maybe February,
March is kind of the time you could expect it on mainnet. I know there are people, uh,
who wanted earlier than that. Um, my engineering perspective is let's be careful. Probably faster
is difficult to get and let's see how these discussions go. And there's always possibility
of like unseen, um, problems that arise. Like if testing goes, goes wrong, like obviously we would
kind of have to, to delay it. That's why we are testing it. So that's roughly what you can expect.
So yeah, we, we wanted as soon as possible. We've done a lot of work. Shouldn't take too much longer
for Vazen. In Vazen, that's like a completely different story. We have a couple of ideas floating
around. I haven't seen even the start of a proof of concept implementation. I think we're still in the
very early design phase. So giving you any kind of date when you can expect that would be a lie.
I can tell you it's definitely not going to be within the next six months. After that, let's see.
I'm also excited about Vazen in Vazen.
Um, but yeah, it's very early.
So on the previous question, Jacob, um, you talked about the timeline for the meta transactions.
Once that's done on the chain or the, the protocol level, um, is the relayer has to
do any changes on their side? Like who wants to kind of, um, use meta transaction or is it ready to go?
Um, yeah, right. Um, always focused a bit too much on just the protocol side here.
Of course we can put it on mainnet, let's say in February. That doesn't mean it's actually usable by
users yet. Uh, but given some partners that I know of that are really kind of keen on getting their
hands on it. I think they will start test testing it as soon as it's on testnet. So they will probably
have their setup already, um, kind of working during that phase. And if they're comfortable after their
testing, they can, it, I would expect that we can see within like the first week when it's on mainnet
that actually is the first, uh, relayers will be out there. Uh, the question is, will it be like a
general purpose relayer or one that's specific for, for the use case? Um, let's say you have your,
your own fungible token, um, on your protocol and you want to be able to, to enable people sending
those tokens between them without having a near account. Now you can put up a relayer that allows
only doing that. So you really, you can only help your users sending fungible tokens among each other.
Um, and you are going to pay for it. Um, like using to paint the gas for it. So that kind of, uh,
implementations I expect to see quite quickly. Um, general purpose, I would expect to take some
longer, uh, some more time people want to be, I mean, anyone here in the call could be implementing
it. So let's see where it goes. I hope it will be soon. Awesome. Yeah. That makes sense.
Okay. Um, we're, we're about six minutes to close. Um, again, another thing that I'm thinking of doing is
I'm making notes from this call, like all the links that we want to share. We can also tweet
as an after, uh, office hours response or a thread that we can create that way. Folks who have been on
the call are going to go back to recordings. They can always find as a follow-up to the question
answered, why are the links? So that is another thing that I'm, I'm thinking of kind of, we can do that
as a practice. If the space seems to be, um, viable for most of them to join and ask questions.
So we can also do as a response, um, to share all the things.
Okay, that's a radio silence. So we have five minutes left. We can wrap up early also,
I believe Josh, right? Um, if there are no comments, questions, suggestions, um, one last
thing, again, I want to plug back in, which I shared early in the call was to, um, create
that community space for us for each different focus area, like protocol level, different validators.
I think Patrick, um, you asked a lot of RPC and indexer, um, a node specific question.
So we can create a unique community, um, even though there's discord, but I think we are looking at
a both async and sync where in community can focused on a specific area, can meet often and
exchange ideas and share, and also find a way for you guys to propose those ideas and document
somewhere in the GitHub, uh, which we already do, I believe in discussions and issue GitHub issues,
which gets, uh, created. Um, however, we want to kind of formalize all of those process. Um,
so that way there's some way as an inlet and also as an outlet, create a loop for you folks,
um, and create a community platform or group. I don't know how to specify that. So that way,
you guys help each other out, not just us being there, but we'll also be, um, present most part
in that, um, where, and we can have kind of substantial conversation and meaningful conversation,
uh, as well. So yeah, go ahead, Patrick. I mean, can I just walk you guys through my journey real
quick? Cause it seems like everyone's pretty silent. So, um, I was working on a contract. Uh, I tried,
um, I tried, uh, making some changes and then I deployed it. Um, and, uh, I, and I had to clear
the contract state. So I had to view state keys. I couldn't call, make a view state keys because
that transaction wasn't, uh, supported by public RPCs nodes because the tree viewer state size limit,
I had to set up my own RPC node, go and go through the documentation on how to do that. There's no
Terraform. Um, you know, there's no cloud formation template. It's all manual. So I had to do that
manually. Um, and that, that, that was, that was fun. Uh, you know, and, and then, you know,
it's just like one thing after another for, for making a different changes. And now I'm running
into a gas exceeded limit. Um, I'm just kind of curious, um, you know, it just, just feedback,
right? Like, uh, you know, I'd love to provide this feedback, uh, you know, provide a place where we
could, if GitHub issues is the place to provide that, if this court is the place to provide that,
that's great, but just, you know, um, like actually using and going through the developer
experience and workflow, um, you know, if developers have a good way to provide that
and then constantly thinking of like, Hey, how can we improve the, the DevEx, right? So workspaces
is a really good example of, of, of one way to improve DevEx, but just a forum where, where developers
can also help contribute to improving DevEx in the ecosystem. That'd be, that'd be awesome.
Um, that's a great call out. And thank you for sharing that. Um, definitely. We're looking
in that space and I think the best way to do, um, is to use GitHub issues, um, to provide your
feedback or suggestion rather than discord discord. It's hard to kind of, uh, maintain and monitor
as far as far as I understand. So if GitHub, at least there are folks looking at that. Um,
if you could still provide whatever information you provided and the, the, the bottlenecks that
you've hit or the wall that you've hit, if you can share details as GitHub bugs or issues, I don't
know how that is being created, but if you create one of them and eventually we want to formalize that
process. So that way you have a way to go provide that information for us, for us to understand.
And if it is a quick question, sometimes Zulip, a lot of folks, engineers are always on the Zulip,
um, platform. So that's more accessible from the developer side of things, um, who is more
available rather than discord. Most of us are not on discord if you're looking at engineers and
their responses. So I would highly recommend those two. Like if you have a question,
um, try discord, of course, uh, there could be other folks who might know an answer to you,
but it's hard to manage and discord than any other place. So yeah, I'll, I'll help formalize
this process, but meanwhile, go ahead and do it and get help as an issue. Cool. Thanks.
And the dream of course, is to talk about this on Twitter and have
Eugene and Frohl and Bogdan and Bowen chime in and everyone kind of talking about it.
And then people from different ecosystems and different blockchains see a really cool
and interesting problem. And then they get interested in there. I think that's another
like really fun thing that I'd love to see like next year. Awesome. That's, that's amazing idea,
Mike. Um, so that's as a followup. So we don't have a specific process anywhere in place
or a way or a flow. So let's establish that and then eventually get people talking or we can do it
in parallel impact, right? So Twitter, uh, we can always leverage that for broader, uh, engagement
and involvement and it kind of generate interest as well. So definitely we will use that. So we had
actually a time and this has been really, really meaningful conversation for us. Um, so thank you for
all of you being here. Um, and we'll see you next week again, same time with a new topic, which we will
tweet ahead of time. So thank you all. See you. Awesome. Thanks. Thanks Shatna. Thanks Jacob. Thanks
Mike, Patrick and everyone else. That was Dennis, uh, all y'all joining and, uh, yeah, being a part of this.
Really appreciate it. Aloha.