[Applause]
hello everyone looming today I'm here
discussing our meta transaction tree
layers so what are the transactions
first benefactors enable fund lists keep
bears too and use smart contracts rather
than spending gasps they signed their
intended action and using their private
key and then a new layer broadcasts on
their behalf and pays the associate
entities so that bloom in the past year
we've submitted over 250,000 of meta
transactions on bayonet sometimes it has
six six thousand management actions in a
single day during this time we were
spending up to one to three eat per day
just to keep our benefits actually was
going this has to do with like identity
credential issuance so what we've
learned pretty early on is that simply
broadcasting the transactions does not
scale you can't just call web 310
directly to SMEs and hope that it's
going to work confirmation times are
long and they're inconsistent gas prices
can be volatile and there are frequently
trade chain reorg switch drop
transactions so the first thing that we
encoded into this service which handles
very high volume transactions is non
store casting so the in a simple piece
on the left you can see that we
broadcast one transaction witness one
zero zero one and everything else is
blocked so they can't all be mined in
the same block instead what you can do
is use the nos field of send transaction
so that you can do one thousand one
three one thousand five and you can have
all of these tapped into the same block
without waiting for mining when there is
a non set blocking the next one so if
we're waiting for one zero zero two two
mine we need to aggressively rebroadcast
that transaction with a high of gas
until it goes through so this happens in
the service every 30 seconds it
rebroadcast with a point one Waymire gas
price in order to force it through so
that every other transaction will endure
blocked we found that on an average each
transaction needed to be broadcast twice
to go through so this when I set up this
inelastic sac when I looked in the
morning this look healthy to me
there were transactions being created on
the bottom and then they were being
committed or rebroadcast on the top gas
prices sometimes spiked very high that's
important to set a cap and wait it out
because gas prices are volatile but if
we filter out everything above a hundred
way it's actually pretty consistent so
if you were spending you know maybe
somebody has some arbitrage opportunity
way back in a sip end in February you
didn't want to be competing with every
gas
just wait a little bit and then you can
get your transaction through our actual
spending ended up being far less than
the average but we still have very high
throughput also during when the network
is very congested mining will sometimes
lag by many hours and you might be
concerned that it'll never catch up but
as soon as the number congestion goes
away the backlog clears and then you're
broadcasting at mining times get much
closer together one last thing that you
also shouldn't look for is chain reports
so we have first you think that
something was mined but later your
transactions are not being broadcast you
should go back and look at the most
recent transactions see if it's dropped
and then you can either fulfill it
value exacted or you can actually go
back and read broadcast at one so
finally I just open source this about
ten minutes ago this service that
actually handled all this logic for you
and it's very balloon specific now you
actually have to encode a lot of the
contract logic that I would love that I
try to get some other companies set up
with this service it does a lot of a
camel a lot with us awhile to the to
figure out so please take a look
let me uses PG boss for the queuing is
all paid script so use type chain for
contract leggings check it out and every
little T with it thanks
[Applause]